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

[Ilya Goldberg]

I'm not disagreeing with you as much as you think.
Of course we'll end up writing both ends of the interface in many 
cases, but its good to keep an eye out for opportunities where we can 
get some bonus interop because we don't want to write every possible 
client ourselves.
Of course we don't want to *base* our server infrastructure on 
connectivity with Excel, but connectivity with Excel is monumentally 
important.
Its not an OR thing.  Its an AND thing.  It has to be.
-I

On Jul 7, 2005, at 3:56 AM, Chris Allan wrote:

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