[ome-devel] Shoola-back-end consistency issues

[Ilya Goldberg]

On Jul 6, 2005, at 5:38 PM, Chris Allan wrote:

>
> We're not developing a word processor and we're not Microsoft. Ever
> looked at your Finder Ilya? It doesn't have update buttons. That's
> because if you go to the terminal and type "touch file" and you've got
> that Window open Finder gets notification of a change in that folder 
> and
> updates the display. That's what we should be striving to accomplish,
> not auto-update for your spelling mistakes.
>
> You are the Mac lover right? Microsoft GUI concepts and HCI are 
> horrible
> right? Should we resort to Microsoft-esque "Press F5 to Refresh" or
> would you like the nice clean notification API and proper
> synchronization?

This is getting a little out of hand.
Mac lover, eh?  I've programmed computers big and small long before 
there were Macs or Microsoft (not to mention certain actual people who 
insist on maligning me).  I can't say I particularly love any of it 
(except for said people).  I've seen a lot of tech come and go in that 
time, and then come and go again.  There's nothing particularly new or 
exciting here - we've seen it all before.  Go read the original OME 
whitepaper and see what we were all hot and bothered about back then.  
Its not bad stuff, its just too damned hard to work with and it hasn't 
gotten any easier.

I think notification is difficult in a distributed system like this.  
If you think its easy and worth-while, be my guest.  But I think there 
are better ways to spend our time.  There is a simple solution to this 
we can have tomorrow if we wanted to.  Or we can wait X months/years 
for ICE/Jxxx/Whatever.  But one thing I know for sure, simple and good 
enough always wins in the end.

If you want me to say that ICE is a good idea, I'm sorry, but I just 
don't think that it comes out well in a cost/benefit analysis.  
Primarily because you will always be writing both ends of this 
interface - there's nothing worth while we want waiting for us at the 
other end of this thing.  Its somewhat less true of various Java 
doodads.  I'm most interested in interfaces that I only need to write 
the one end for.  Connecting easily to Excel (and SpotFire, and other 
doodads like other people's web services) will always be a bigger win 
than connecting to some middleware abstraction.  I don't have to write 
Excel, but likelier than not I will have to write whatever it is that's 
on the other end of that middleware.  The middleware wars came and 
went, man.  The verdict was that its all too damned complicated, and 
the promised interoperability never happened.  That's why we have web 
services now.  And now we have new attempts at middleware again, and 
these will lose to web services even if they're better, because web 
services are simple and they're good enough.  And so it goes.

But who am I to say.  Maybe this time it'll stick.  I can't help but 
think that we are better off spending our time trying to connect to 
functionality we want that doesn't terminate in a pretty abstraction, 
but real tools that actual people use to do real science.  If buying 
into a java middle ware gets us some collection of these things, and 
lets us write better clients besides, great.  But we need to maintain 
the simple and good enough also, because that's what most people will 
use.

I think I'm pretty much done with this thread either way though.  Y'all 
flame on!

-Ilya




>
>>
>> -I
>>
>>
>>>
>>> Ciao.
>>>
>>> -Chris
>>>
>>
>
> Ciao.
>
> -Chris
>