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

[Chris Allan]

On Wed, Jul 06, 2005 at 09:08:01PM +0200, Josh Moore wrote:
> Harry Hochheiser wrote:
> > Josh, et al

Hiya all.

> 
> > Is this one option or two? 
> 
> Two technologies. _Many_ implementations.
> 
> > And ICE and Java play nicely together, right?

Yep. ICE has a messaging protocol and a set of middleware notification
primitives all wrapped up under the IceStorm name. It doesn't provide
some "magic" to do notification for you. You still need to design the
notification channels, register for them, etc. Much like events. ICE and
Java play very nicely together and if you're so inclined the client
and/or server could be C#, C++ or Python for example.

> Yes and no. Interoperable, certainly. But ICE gets you a whole hell of a
> lot of stuff as does Java. It doesn't necessarily make sense to use all
> of both of them.
> 
> And if you mean something like Java/JMS client ICE/messaging server -
> no. There aren't any backbones to make that happen. Unless Chris tells
> me otherwise. :)
> 

As Josh mentioned you don't get some magical integration, if you want
existing Java technology to work with ICE you have to make it work with
ICE. ICE is a *language independant* technology. There is nothing,
anywhere, that ties it to any particular Java technology.

> 
> > I'm not sure what you mean by this. In what way is MEX not clean?
> 
> Jean Marie and co. can point out the situations in Shoola that they've
> run into. Basically comes down to the fact that some DB "state" changes
> may come from a source other than the AE. If by definition all state
> changes in the DB happen due to a module, then this is solved. Or if
> there is a superclass of MEX which contains all such events it's solved.
> At the moment, things are a bit twisty _as I understand them_.
> 

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

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.

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