gnue-dev
[Top][All Lists]
Advanced

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

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


From: Jan Ischebeck
Subject: Re: [Gnue-dev] Halloween 5: Appserver Architecture
Date: Mon, 4 Nov 2002 00:24:32 +0100
User-agent: Mutt/1.4i

On Sun, Nov 03, 2002 at 09:01:04AM -0700, Derek Neighbors wrote:
> 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.

1. It is an important aim to write code once and have it working in both
2-tier and 3-tier setups. We should try to make it possible.

2. If code can be reused it should. But the code in appserver to make
methods work and the code in common for the trigger system have
different design criteria. As I stated before I will try to reuse and
enhance the common trigger code, but I'm not shure if its possible.

> 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.
> 
The "job" of both "plugins" are quite different.
The authentification plugin in common FETCHES (f.e. from the user) 
authentification information to provide it to databases/middleware etc. for
authentification. The auth. plugin of appserver gets some information
(f.e. information, which was collected by the first plugin used by
forms, reports etc.) and validates it. 

I really like the idea of having common, but I don't think that
everything has to be moved into common at once. I would prefer to first
implement the appserver auth plugin in appserver and wait till any other
application needs stuff like that before moving it into common.

> > We have also talked about the definition of "views", that is the
> > possibility of creating different "masks" that are puts over the
> > business objects depending on the user. Like:
> > * User joe sees all customers with all their properties
> > * All users from sales see all products, but they don't see any purchase
> > related properties of the product objects
> > * Users from the sales department only see the customers of the region
> > they are responsible for
> > * Every department leader can see all employee objects, but the wage
> > property is only writeable for the employees in his department.
> 
> Role Based Access Control or Access Control Lists should also be
> addressed probably in common as ALL tools will need it.
> 
First priority is to implement it, so that appserver can use it. If forms,
reports etc. can use it too, its a nice side effect. But forms, reports
needs a much different and more advanced security structure, so IMHO it isn't
worth the effort. It could even make common work slower.
(I don't think that the user of reports would like that)

> > We are looking forward for feedback.
> 
> 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.  

Please look into the Halloween 2 mail. To use appserver for anything,
you allways will need the rest of gnue. 

> Please use trigger system in common.
if its possibly.

> Please use trigger system in common.
You repeat yourself.

> 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 really like the idea of forms and of having a multifunctional fat client in a 
two tier setup, but there is a need for having a three tier setup too.
Please give us some air to breath, some ideas to implement WITHOUT
having to port them to forms directly. I think that a 2-tier and a
3-tier setup will be used in different situtations, and that many
features just make sense for a 3-tier setup as, are many which just make
sense in a 2-tier setup. 

I really want to get some hints about how you would like appserver to do 
things, what appserver should do and what not. But I don't like to just hear a
"MOVE IT INTO COMMON". I don't think appserver == common, as I don't
need a orcale database coded into forms.

Jan




reply via email to

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