Re: RE: RE: [Phpgroupware-developers] Re: phpGroupware database and uml documentation in wiki?

[Dave Hall]

Kai Hofmann <address@hidden> wrote:

> Hello Dave,
> 
> > > The database model and the software modules that are working 
> on it
> > > are two different things. 
> > 
> > Yes, this is true.
> > 
> > > As long as you also design the database in
> > > different modules without interaction between the data (relations)
> > > you have no real groupware (from my point of view). 
> > 
> > There is interaction between the the apps, and this is planned 
> to be
> > strengthened.  But phpgw is an app with a collection of apps, 
> not a
> > super project.
> 
> phpgw is an api and a database with basic functionality for other
> groupware modules that depend on the api and the database.

Yes

> The data is important for a groupware because a groupware
> integrates data instead of having a single application for each
> work process.

Yes, that is the purpose of the API and the clasess and db schema which
are part of it.

> 
> > > When having a whole database as in my example - you don't need
> > > something like infolog for the data communication (between the 
> > > modules).
> > 
> > Yes but phpGW is more than a db.  I think the db can be worked 
> on and
> > tweaked a little, but the model can not expect that there 
> > will be app X
> > installed for it to work.  phpGW is designed to be modular, with
> > integration not a set collection of apps with inter 
> dependencies. 
> 
> Here are two points:
> 
> 1) A database mainatiner is required 

Maybe, I am yet to convinced of this.

> - which task is to maintain 
> the db api
>   as well as the "central db-schema" (in cooperation with the module
> mainatiners).

what is the "central db-schema" ... in my mind the "central db-schema"
is the api schema.

> 
> 2) The data is the important thing 

Without data we have nothing

> - thats for example the most import
> concept of
>   object orientation.

Yes and you access that data via the objects.


>   So a new phpgw module can work on existing db tables/relations 
> as well as
> connect
>   its own tables via new relations to the existing db (without any
> problem).

This is true if a developer wants to access to data of another app ... 
but in order to implement the security system designed by the app/class
developer ...  this is acheived via a CreateObject('app.bo_obj) or
ExecMethod('app.obj.method') function calls.  This is also resolved by
the dependency functionality in the setup app.

> 
> As a result it would be possible to have different (for example 
> adressbook)modules
> that are working on the same db tables/relations. One of these 
> modules might
> be more
> simple and unse only a part of whats possible and the other might 
> be more
> complex and
> add some extra data to the model.

This is what I have propose for the email app.  The basic email sending
functionality is present in the API and the relevant user settings. 
This would also resolve the circular dependencies involved with the API
and the default email app (aka anglemail), and also allow sysadmins to
only install felamimail as the only email client.


> The advantage is that you avoid redundant data and that you have a 
> muchbetter
> interaction between modules that need the same data (adress book 
> and project
> manager for example).

I do not use the projects app, and so would not be happy having the
projects app schema installed, just because it seemed like a good idea.
 I have a test/dev environment with all stable apps installed, but this
is not my day-to-day install.


> 
> For the moment the proble (as you know) is that every module 
> reinvents a
> part of already existing (in the phpgw)
> things.

What do you mean by this?  If apps use the dependency functions in the
setup app, and use CreateObject/ExecMethod then this is a non issue imho.

> 
> Btw. its no problem to install a complete database schema in a db 
> and only
> having one module that
> works on a small part of it!

Ummm ... i disagree.  Interlinking between apps is via the setup app and
CreateObject/ExecMethod functions of the API.  This ensures dependencies
are properly dealt with, and also ensures ACLs are enforced.  

I think what you are suggesting is that we ditch security and just allow
any app to have free reign over the db via direct calls.  I do not
support this proposal.  We have bo/so objects and app specific schemas
for a reason.  Not everything can be imposed at the rdms/so layer, that
is why we have smart bo objects - to allow for flexible security.

Oh, one more question.  Why do you have so much confidence in phpGW/Free
Software projects, when you still use the M$ LookOut/Explain combo? 
Just curious :)

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>