Re: [Gnue-dev] Reinhard's white paper

[Reinhard Mueller]

Neil,

thanks for your comments. That's exactly what I wanted: provide a
starting point for a discussion :)

On Wed, 2002-02-27 at 01:24, Neil Tiffin wrote:
> 1) Technical Goals
> 
> - central repository for defining business rules, methods and data 
> that does not require a software developer to adapt to the business.

Agreed. I have put that between security and performance
(priority-wise). I hope you agree on that.

> 2) GNUe Object Access Translator (GOAT)
> 
> Security at the GOAT level will select or reject database rows based 
> on the users authorizations to any regular query.
> 
> Example:  if the division president uses a form to request all sales 
> orders, GOAT will query the database and return only the object data 
> that represents the divisions sales orders.
> 
> Form level (view) security will not be enforced by GOAT.
> 
> GOAT will also provide object transparency.  Meaning that there will 
> not necessarily be a direct relationship between business objects and 
> tables.

Agreed and added to the document.

> 3) Sorry but I don't like the acronyms.  Not a big deal however.

:)
I don't like them either. I would use them only for internals (e.g.
function prefixes or the like). However I'm not sure if such prefixes
are needed in python.

> 4) I think we have more modules than are contained in the white 
> paper.  Reinhard did you see my latest diagram or did you have a 
> different concept?
> 
> (http://www.gnuenterprise.org/modules.php?op=modload&name=NS-My_eGallery&file=index&do=showpic&pid=31)

Sorry I didn't catch the "blue represents GEAS" and didn't know what is
considered part of GEAS and what isn't.

> Suggest we add
> - Security Adapter (we need to consider LDAP, Active Directory, Kerberos)

Could it be that this is new? I can't remember it being there last time
I looked. Maybe I overlooked it.
However I don't understand what it's role is, so it will for now be an
empty chapter in the whitepaper.

> - Remote Protocol Adapter (CORBA, COM, XML-RPC or other RPC)

You are right with that. 

> Feel free to make up more acronyms.

I didn't dare ;)

> 5) As shown in the Drawing (mentioned above) I think that GEDI is 
> actually several modules.  One module for each database to implement 
> the protocol to communicate with the database. And one SQL generator 
> module for unique class of database.  It may turn out that each 
> database has its own SQL generator. If so, thats ok.  But the SQL 
> generation should be separate from the interface.

I've added some comments about this and would like to know if you agree.

On a complete different topic, I want to bring up the question whether
we should also name the new incarnation "GEAS" or if we should find
another name.
Pro another name: The concept will be different from what we have now,
it will be clear that it's a complete rewrite, and it will be clear that
previous documents that mention "GEAS" don't relate to that what we are
doing now.
Con: I can't think of another name. Maybe only GNUe Appserver (like GNUe
Forms, GNUe Reports...) to be consistent with the other blocks.

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