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

[Chris Allan]

On Wed, Jul 06, 2005 at 09:55:07PM -0400, 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'm still calling you out on the "nobody uses notification systems"
statement. The fact is people do use them and they use them where
they're useful and where they're irritating.

> 
> 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.

Ilya, we're what 3? 4 years into this project? What large task affecting
more than one person that we need to accomplish did you think was going
to be "easy" or "simple"? If you well and truely think polling is going
to make our client developers lives easier, just ask your own developer.
Currently, he actively chose to not implement it. Do you think that's
because it was simple and easy? It take 5 seconds to write a refresh
button and it takes weeks and months to deal with refreshing the amount
of data we have and the complexity of the display of that data.

> 
> 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.

So our large overarching vision is to use Excel and Spotfire, a
spreadsheet and a database visualization tool to drive our server
architecture?

We have a rich client infrastructure Ilya. One of your guys has actively
written some really interesting stuff for it with some cool user
interface concepts. We're *already* writing both sides of this interface
and that's inevitable as long as Shoola exists. We're all sitting here
throwing around ideas on how to make that *easier* for the client
developer. Or have you decided that what up until two weeks ago amounted
to three developers are now responsible for implementing a polling
infrastructure across some five fairly sizeable pieces of code?

(ZoomBrowser, ChainBuilder, Viewer, HiViewer and Data Manager)
 
> 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.

We're *already* using tons of middleware, middleware we all chose to
build ourselves, including DBObject and the Remote Framework. Just
because we didn't choose to use JBoss, WebSphere or some other honking
Application Server doesn't mean we don't have middleware technology, we
do. For every person that wants the simple and good enough we will also
have the people who want a clean, published remote interface that they
can plug into using a client of choice and use.

The largest integration partner we have right now is the VisBio crew.
Are they directly connecting to the DB using JDBC because it's simple
and easy? No. They actually don't want to implement all of our analysis
engine logic themselves just so they can use that DB directly. Did they
write a ton of XML-RPC code in Java themselves because we published some
web services? No. They're using our library, the fact that it's XML over
HTTP, and we can call that a web service if we so desire, is irrelevant.
If it was CORBA, ICE or some proprietary protocol they'd be using that
too.

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

flame++

> 
> -Ilya

Ciao.

-Chris