gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel E Baumann
Subject: Re: [Gnue-dev] First draft for an API of the GNU Enterprise Application Server
Date: Wed, 13 Mar 2002 09:46:38 -0600
User-agent: Mutt/1.3.27i

On Wed, Mar 13, 2002 at 02:53:39PM +0100, Reinhard Mueller wrote:
> 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.

Ah, yes you have a point there ;). I haven't thought much about that,
but your session object does make a bit more sense now. I do have a
rough idea how things will work and I will attain a better one once I
look at how client programs use the ODMG interfaces (there's a c++ and
java binding in the book) and then relate this to the app server. I am
basically trying to see what can be pulled from it, before I go off
designing some of my own stuff.
 
> > 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.

Yes I suppose that is what will dictate things, however from what I see
there will be an OQL interface and an Introspection interface. Of
course this is all heresay, as I haven't fully thought about it or
finished working out all the details.

-- 
Daniel E Baumann      address@hidden

And if cynics ridicule freedom, ridicule community...if ``hard nosed 
realists'' say that profit is the only ideal...just ignore them, and use 
copyleft all the same.
      -- RMS



reply via email to

[Prev in Thread] Current Thread [Next in Thread]