Re: [Gnue-dev] First draft for an API of the GNU Enterprise Application Server

[Reinhard Mueller]

Daniel,

Thanks for your feedback.

Am Die, 2002-03-12 um 22.25 schrieb Daniel E Baumann:
> On Mon, Mar 11, 2002 at 10:34:37PM +0100, Reinhard Mueller wrote:
> > The Appserver Whitepaper has moved to
> > http://www.gnuenterprise.org/~reinhard/whitepaper and a first draft of
> > the API is available at http://www.gnuenterprise.org/~reinhard/api in
> > all the usual formats.
> 
> I don't really see much of a difference between your 'session' object
> and what exists already in the current geas as a 'connection'
> object. In fact I thought we might build a more pluggable
> authentication framework ans implement 'permissions' stuff in an RBAC
> way. The way I see it, the plugin loading would be very similar to how
> the db drivers and gnurpc will load it's 'drivers', but this is more
> of am implementation issue (look at dyn_import in
> gnue/commmon/src/__init__./py). What we need to do is define factory
> classe(s) and the interface those plugins will implement.

This sounds good. However I guess this is _internal_ to the Appserver,
while the interface I was trying to describe is the interface the
Appserver shows against Forms or Reports. So I'm not sure if we talk
about the same thing here.

> For Transaction objects I would use the current transaction.idl as that
> interface is exactly the on from the ODMG standard and it includes more
> than just commit() and rollback(). It also specifies
> a TransactionFactory class. (I would look at the standard in odmg.txt
> for the full interface). Also my notes on how transactions work and
> what exceptions are thrown when using transactions objects incorrectly
> is also very useful.

Thanks for your pointer. I will look at your text in more detail.

> Wrt list objects, ODMG defines various collections (set, bag, list,
> dictionary) which may not be immediately apparent to their usefulness
> in regards to business objects, however I have now come to find out
> they are extremely useful in doing OQL queries. If you say 'select
> distinct' you will get a set object otherwise you get a bag object (a
> set that allows duplicates). I think these collections need to be
> implemented.

Not sure if sets, bags and dictionaries make sense for us. IMHO it
mainly makes sense to implement functionality that GNUe Froms and GNUe
Reports will use. I think we should try to implement _that_
functionality according to existing standards, but I'm not sure if it
makes sense to implement functionality that will not be used, just
because there is a standard for it.

However the Forms and Reports team will have to decide if they find it
useful to be able to request sets, bags or dictionaries of objects from
the Appserver.

> I know this is a 'rough' API and I am going to force myself to
> define/refine some of the architecture/API and release something by no
> later than this weekend and perhaps we can merge some ideas. I just
> thought I would say a few things as you did ask for feedback ;). 

Thanks again,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org