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

[Chris Allan]

On Wed, Jul 06, 2005 at 03:53:18PM -0400, Ilya Goldberg wrote:
> 
> On Jul 6, 2005, at 2:04 PM, Josh Moore wrote:
> 
> >Before I respond to the previous points let me add at least one more
> >suggestion to the following list.
> >
> >- - Messaging. In the Java world, there's JMS (also with cross-platform
> >capabilities); in the ICE world, Chris can give you a shopping list of
> >opportunities.
> >
> >- - Distributed objects: Again, Java world has Jini/JavaSpaces, RMI and
> >Corba, again Chris will tell you what all ICE can do.
> >
> >These are both technologies that make _everything_ a bit more
> >complicated, but once we've committed, we can take full advantage of
> >various patterns that we haven't add available to us yet. Basically
> >close-to-real time systems. Just a thought.

Just want to address the following, the rest I've pretty much said my
piece.

> 
> Great, and when client X modifies the DB using VBA/.NET, which magical 
> messaging and distributed objects pattern will ensure that client Y 
> using ICE will update itself to be consistent?
> Presumably these modifications would end up being processed by some 
> back-end aggregator that will then go and issue messages to any 
> connected clients to update themselves.  This aggregator will have to 
> perform translation services for any and all interfaces used by 
> clients.  Will it go and update the Web UI the user's got open also?
> 
> What about clients that connect via JDBC/ODBC?
> 
> I don't think there are any magic bullets here.  If we want a 
> monolithic system where we control all of the ins and outs explicitly, 
> this all becomes fairly simple using whatever we pull off a shelf.  If 
> we want a system that's maximally open with many ways in and out (the 
> "O" in OME), then this becomes a more difficult (not to say 
> interesting) problem.  When deciding on these interfaces, we should be 
> thinking "Who and what can we afford to exclude from access into this 
> system?".  Its instructive to look at a long list of real-world systems 
> that we need to talk to - not hypothetically sometime in the future, 
> but like yesterday.  None of these things use ICE or Java or anything 
> even remotely that intelligent.  Some can do web-services or at least 
> pretend to.  Its really these systems that we need to concentrate on 
> talking to.  As far as clients that we develop, we have pretty much 
> free reign as long as we don't close anything off in the process.

I'd really like us to think about ourselves a little bit for once.
Helping out others who activly decide to do their own thing (code in
VB.NET using SQL# or access the DB directly using JDBC/ODBC/DBI, etc.)
is one problem, helping *ourselves* is another.

If a third-party decides to actively choose to circumvent our attempts
to make their job of handling notification easier, so be it, there's
nothing we can do to help them if they choose that road.

Focusing on what we need for Shoola and possibly extended to Visbio and
some events for the web interface to pickup on page loads is what I
believe we need to do here. This topic did not come up from some random
outsider, it came up from real users using *our* clients to connect to
*our server. Lets deal with those requirements.

Ciao.

-Chris