Re: Status of the ozone project

[Martin Harper <mcnh2@cam.ac.uk>]

Falko Braeutigam wrote:

> Hi all,
>
> I have to forward this message, which I sent to Raul some days ago after he
> unsubscribed the list, to the list because it IMO reflects the status of the
> ozone project very well. Comments are - as always - welcome.

ok.... (this is longish)

> ----------  Forwarded Message  ----------
> Subject: RE:
> Date: Wed, 13 Sep 2000 12:29:05 +0200
> From: Falko Braeutigam <falko@softwarebuero.de>
>
> Hi Raul,
>
> I very appreciate your honest answer.
>
> On Wed, 13 Sep 2000, you wrote:
> > Thank you for asking.
> >
> > I was very interested and I have been studying ozone much.
> > But I had serious problems with Ozone:
> > - I had a difficult Exception message I until now have not solved.

On a sidenote, it would indeed be good if the exception handling of Ozone was
cleaned up. As I see it, the main problems are...
Many methods on Ozone are declared as throwing Exception, whereas it would be better
if they could throw just OzoneRemoteExcs, and possibly some others, like IOException
(haven't checked code).
OzoneProxies generated by OPP rewrap exceptions in unexpectedexceptions - but the
wrapping only wraps the string from getmessage - it would be better if they were
more similar to java.lang.reflect.InvocationTargetException, and wrapped the entire
exception. On a similar note, they should probably not touch the stack trace.

In any case, the logger on the server tends to be the most useful for tracking down
bugs - at least for me.

BTW, It'd be neat if OPP flagged uses of this where self() should be used in *Impl
files - that'd be one less source of bugs... :-)

> > I still appreciate all work that has been done, but to me it looks like
> > ozone needs a total clean up and a strategy overview.
> ozone needs a clean up and a strategy overview? Fine! What are your ideas? I'm
> totally open minded in this regard. And, even more important, why don't we
> discuss this in the list?

I do think a fully-fledged ODMG wrapper to Ozone would be good, if a lot of work -
the current interface is great for internal stuff - between different modules of the
same program - because you can do all the database work in a single
implicitly-transactioned method call, set up precisely as it's needed, and optimised
to do the work in the best way possible. Unsurprisingly, really, since that was what
it was designed for...

However, if you're writing middleware, and you have to provide access to parts of
the database to external programs, then you're in trouble - you either have to make
the types of access very limited, or you have to implement a proper query language,
in which case you might as well pick OQL because it's the one everyone else uses.

It's also difficult to get Ozone to dynamically optimise itself for the type of
queries it's receiving - as an example, I store a bunch of computers in Ozone, and
some simple information on each. What's the best way to store them? If I hash by
name, then it'll be dog-slow if most of the queries are based on IP. If I hash by
IP, then it'll be dog-slow if most of the queries are based on name. If I make two
hashtables, one for each of IP and name, then it'll half the speed of adding and
removing entries. It gets worse with people, who have about 50 different attributes
each...

That could be fixed with a new subtype of Set , perhaps, though I expect that too
would be a lot of work. But defining a skeleton class for it now and a simple (slow)
implementation would be a good start. Preferably one that implements java.util.Set,
rather than .DxLib.DxSet - better yet if it implemented org.odmg.DSet. Seems like
the sort of things someone somewhere else has already done... I hope so.

Umm... that's it... :-)
Martin