----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Friday, December 31, 1999 1:56 PM
Subject: Re: OPal and DODs
> Scott, jon, and anyone else interested in opl
>
> --- Dave <[EMAIL PROTECTED]> wrote:
> > Just FYI -
> >
> > You guys may already be aware of this, but I'd
> > thought
> > I'd throw it out anyway. There's an open-source
> > project (under a Free-BSD
> > style license) called Enhydra. They have an Object
> > to Relational tool
> > called
> > DODs that has some nice features to include an Swing
> > GUI. Take a look:
> >
> > http://www.enhydra.org/doc/DODS.ht
>
> Based on this info, it's a good time for an opl status
> report.
>
> OPL has CRUD (create, retreive, update, delete)
> functionality. I've lightly exercise most of it. So,
> we have this, criteria and sql statement generation.
> Some work remaining to support more data types.
>
> The functionality for associated data (the uda maps)
> is coded but untested. The system really needs a
> class map loader before spending time on testing this.
>
> Useful functionality that is not implemented is
> something for generating OIDs, something to use
> timestamps for the "optomistic" locking, transactions,
> and a loader for the class maps.
>
> Only difficult job there is transactions.
>
> I don't see any value in the other stuff in Scott's
> paper. Java natively supports most of it. Only other
> thing is Proxies. Definitely, people should use
> proxies in applications. But, using full-fledged
> objects for proxies is simpler, less confusing, and no
> more work to implement.
>
> What's really missing is tools to do the work that DOD
> does. Something is need to generate classes, class
> maps, and sql table create scripts.
>
> -- george
>
Well I know that I have done this a number of times already but I think that
George deserves many thanks for all the work he has done in such a short
amount of time, so George.... THANK YOU! Now I know that since I've first
committed the original OPaL code, my work on it has been scarce if not
non-existent. The reason for this is two fold, first: stringent time
constraints (work, holidays, family... etc.), second is some technical
problems I can't seem to get past, so for that I apologize.
Now as for the Enhydra/OPaL issue. First I do not have a bad think to say
about Enhydra, from what I can see it looks like a good product if it solves
a problem for you (just like anything else). But here are my thoughts on it:
Enhydra is an application server that happens to have the feature of object
mapping and if that's what your looking for then by all means use it. But if
you are going to use just to get the object mapping (object persistence) you
are going to get allot of other baggage along with it. OPaL is as its name
describes that is being developed as a part of Turbine which is an
application framework hence not an "application server". So, with that said,
when you are comparing Enhydra to OPaL, you are not making an
apples-to-apples comparison. An apples-to-apples comparison for Enhydra
would be to products like Forte' or SilverStream with the exception of
Enhydra being open source. As for Turbine/OPaL an apples-to-apples
comparison would be (and a bad one at that) MS's MFC or PowerBuilder's PFC
both of which have been traditionally called Foundation Class Libraries and
IMOP this is the "classification" that Turbine/OPaL fits into. So choose
your weapon of choice....
just my $0.02
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
