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

[Ilya Goldberg]

On Jul 6, 2005, at 3:35 PM, Chris Allan wrote:

> On Wed, Jul 06, 2005 at 09:08:01PM +0200, Josh Moore wrote:
>> Harry Hochheiser wrote:
>>> Josh, et al
>
> Hiya all.
>
> What I really don't want to degrade this into is a situation where
> *every* update to *anything* gets a new MEX. We'd have hundreds of
> thousands of MEXs very quickly that way. Can you imagine the act of
> linking 10,000 images from a high-throughput screen to one dataset and
> generating 10,000+ "copy/modification" MEXs? By definition you've
> modified the images too right? Does each deserve a MEX? Is it just the
> entire operation that gets a MEX?

Actually, the only thing that gets modified here is the ImageDatasetMap 
object, and you can have one MEX for any number of them.  Since the 
ImageDatasetMap is a non-ST object now, it has no MEX.  If we make it 
an ST, you can ask the server "Give me ImageDatasetMap objects created 
since time X".

>  When do they expire? Can I expire your
> notification MEXs? Can you expire mine? If no one expires them how long
> do they stay around?

What are notification MEXes?  If we do polling, then its a simple (and 
fast) query to determine if certain things you're interested in have 
changed since last you looked.  The client knows what its displaying 
and what its interested in.  That's why nobody uses notification 
systems.  Its not the server's business to know what the client is 
displaying or what needs updating.  We should provide sufficient tools 
for a client to quickly determine if it needs to update its state.  
This is mostly true for STs because they are all time-stamped, but its 
not true for all objects.

>
> Artificially keeping state using the DB and Analysis Engine is a recipe
> for disaster in my opinion. Not to mention a serious brain buster to
> decide where modification notification boundaries lie.

Using the DB to keep state is perfectly fine (that's what they're for). 
  I think that notification systems are brain-busters.  Too centralized. 
  Just farm that stuff out - the best place to know what needs updating 
is in the client, not in the server.

-Ilya


>
>>
>>> oh, yeah, agreed.  Unfortunately, we've already gone half-way on
>>> distributed objects. Seems to me that this is the big question:  are 
>>> we
>>> ready to go further down that road?  Personally, I'd prefer not to.
>>
>> I'm not quite sure where half way down the road to distributed objects
>> is, but I don't think we're there. But it is certainly something we 
>> have
>> to discuss.
>
> Right now we're absolutely *zero* way down this road in my opinion.
>
> No object we ever "remote", to use Java/.NET technology nomenclature,
> has a reference on the server. We send the data to the client over
> XML-RPC and we wash our hands of it. The entire basis of our "remote
> framework" is that its stateless and distributed object systems are by
> their very nature stateful.
>
> In order to do this properly, we have to have a stateful server that
> oversees *all* modifications and can notify interested parties when
> those modifications happen. This is nothing new in client/server
> architectures. For those pattern gurus in the house a
> "Publisher-Subscriber" notification system.
>
>>
>>  -J.
>
> Ciao.
>
> -Chris
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>