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

[Harry Hochheiser]

On Jul 6, 2005, at 3:08 PM, Josh Moore wrote:
>> And ICE and Java play nicely together, right?
> 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. :)
>

Bottom line is that we _could_ in theory use one of these approaches to 
provide remote data to Shoola?

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

So, it's the _use_ of mex that is not clean, not its definition.

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

well, we've got a data server that provides flexible access to DTOs via 
a network protocol. Is that 1/2 way down, or only 10% or less? I don't 
know how far we are towards distributed objects, but we've certainly 
taken some steps in that direction

harry