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

[Derek Neighbors]

> The Object Server provides the API described in Halloween 4. Forms and
> Reports access business objects via that API over RPC, while the
> Language Interface translates this API into native language (e.g.
> Python) constructs.
> 
> That means that code using the Python Language Interface will see
> business objects as if they were Python objects.

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.

> 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.

> 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.

> 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.

> 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.  

> The next steps we agreed upon are
> * update the current documentation (README, doc/api, doc/whitepaper)
> * define the system classes for the class repository
> * define the interface between object server and class repository
> * implement the class repository
> * define/document the interface between the object server and the data
> interface and the code interface

Please use trigger system in common.

> * implement the code interface

Please use trigger system in common.

> * define the interface between the object server and the
> authentification interface

Please use security wrapper in common or create one in common that all
other products can use.

> (these steps are in no special order and will probably be done by
> different persons in parallel)

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.

-- 
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