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

Thu Jul 7 07:54:08 BST 2005

Gentleman-

OK, let's tone it down a bit.  No more flames from anyone.

Good critical questions here that we need to answer, and Ilya's  
second two paragraphs below encapsulate a reasonable part of the  
problem.  There are many choices for implementation, and as Ilya  
states the cost/benefit is tricky.  IMHO, there are many cases where  
the salient use case is the Excel/Spotfire one mentioned below.   
There are also others, where the requirements are more tricky, and as  
we have seen more sensitive to implementation choices (browsing  
images, with annotations, heatmaps, etc). This obviously complicates  
the reqs.

Harry and Josh's original question has been addressed and has a few  
possible answers.  We will need to explore these, and get some data.   
Right now, everyone is working flat out on a variety of things, and  
we do have a backlog of items that are critical for user reqs.  The  
refresh button is not ideal, causes us all sorts of problems, but is  
enough for the moment.  Let's see where our resources are at the end  
of the summer and then consider the implementation of this.

Cheers,

Jason

On 7 Jul 2005, at 02:55, Ilya Goldberg wrote:

>
> 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
>>
>>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>

**************************
MSI/WTB Complex
The University of Dundee
Dow Street
Dundee  DD1 5EH
United Kingdom

phone (01382) 345819
Intl phone:  44 1382 345819
FAX   (01382) 348072
email: jason at lifesci.dundee.ac.uk

Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://openmicroscopy.org
**************************