Re: [Gnue-dev] Halloween 5: Appserver Architecture

[Derek Neighbors]

On Sun, 2002-11-03 at 09:24, Reinhard Mueller wrote:
> Am Son, 2002-11-03 um 17.01 schrieb Derek Neighbors:
> > What I am not seeing here is that really method code should be the same
> > as 2 tier trigger code.  I am highly concerned that this is pushed into
> > appserver instead of into common in what currently is called triggers.
> 
> Sorry I forgot to mention this. We discussed it and we agreed on it.
> Appserver will use the trigger code in Common, however IIRC Jan (who has
> looked more closely at the trigger code than me) sees some need to
> change, which he will do in Common, of course.

Cool.

> > > All Class Definitions are stored in the database and are accessible like
> > > normal business objects.
> > 
> > I still think one should be able to store class definitions in flat
> > files if that so fancies them.
> 
> It will be possible to export the class definitions to flat files and
> import them from flat files respectively. This will be necessary (for
> example) for putting our class definitions into CVS. You can't commit a
> database table to CVS :-)

That is sufficient for me.

> > > The Authentification Adapter can authentificate users against several
> > > authorities. It could use PAM to check whether a username/password is
> > > valid, or it could look up the username in an LDAP database, or it could
> > > use an internal business object to store all valid users and their
> > > passwords. In the latter case, it would use the Language Interface to
> > > access these internal objects.
> > 
> > I hope we plan on using the authentication stuff that forms uses?  I
> > think Jason created a 'plugin' of sorts that is in common.  If not the
> > security wrapper should be the same for forms/reports/designer/appserver
> > and part of common as to not 'redo' workd.
> 
> I didn't know that somethink like that exists. We will look at it.

Great.

> > I skimmed VERY briefly so am only giving initial feedback.  Again my
> > worry here is that all this stuff looks good, but basically seems to
> > completely forget that the rest of GNUe exists.  
> 
> I can promise that this is not the case, and i am happy that we had Jan
> taking part in the discussion who could care that we don't forget about
> the rest :-)

Wonderful.  As stated this was observation from a very quick perusal,
not an accusation.

> > Please use trigger system in common.
> 
> Yes. We do.

yeah.

> > Please use security wrapper in common or create one in common that all
> > other products can use.
> 
> Ok. Thanks for this point, it seems I have missed that before.

Well its probably immature so easy to miss, as long as its a 'common'
thing, I think we are set.  That is AppServer uses the same security
mechanism(s) the rest of the tools use.


> > Please before doing any implementation lets make sure all of the core
> > agrees.  Many of the concepts here are going directly against prior
> > mission statements.  I am not saying that means they are not valid or
> > that our mission may not have changed, but I'd rather get some concenus.
> 
> I am not sure if I see the points where we move away from prior mission
> statements. I think some of the points were misunderstandings that I
> could clear with this mail. Please let me know more about the other
> points.

This mail clarifies what was troublesome.  The mission statement I
thought we might have been violating was "All the tools shall be able to
run independent as well as together."  From the response here, it sounds
like that is not an issue and that it is on the fore fronts of those
doing the appserver work.  Which is very reassurring.

Thanks for taking time to address the questions.


-- 
Derek Neighbors
GNU Enterprise
http://www.gnuenterprise.org
address@hidden

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=dneighbo

signature.asc
Description: This is a digitally signed message part