RE: RE: [Phpgroupware-developers] Re: phpGroupware database and u ml d ocumentation in wiki?

[Michael Dean]

On Fri, 2003-06-13 at 04:23, Kai Hofmann wrote:
> phpgw is an api and a database with basic functionality for other
> groupware modules that depend on the api and the database.
> The data is important for a groupware because a groupware
> integrates data instead of having a single application for each
> work process.

InfoLog is a good example of this.  While you can work with the data
that InfoLog integrates in separate modules, InfoLog brings it all
together.

You need to remember that the API is the BASE of phpGW.  User and group
management, database abstraction, sessions, SMTP, NNTP, etc are all
vital core components to groupware.  The "core" applications themselves
should depend on the API, but not each other.  You shouldn't need to
install tables that lend themselves only to modules you may or may not
be using.

> > > When having a whole database as in my example - you don't need
> > > something like infolog for the data communication (between the 
> > > modules).

See above ;-)

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

Yep - tweakage will come later this year.

> Here are two points:
> 
> 1) A database mainatiner is required - which task is to maintain the db api
>    as well as the "central db-schema" (in cooperation with the module
> mainatiners).

I have indirectly volunteered to do this by taking over maintenance of
the database classes and updating schema_proc as necessary.  I have
identified changes in the classes as I work to integrate them with DCL,
and these changes will roll back into phpGW.  As a side-benefit of using
them in DCL (eating own dog food I guess), phpGW will gain Sybase
support and possibly Oracle.

> 2) The data is the important thing - thats for example the most import
> concept of
>    object orientation.
>    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).

phpGW does this today.

> 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.
> The advantage is that you avoid redundant data and that you have a much
> better
> interaction between modules that need the same data (adress book and project
> manager for example).

Also does this today.  Just because the apps aren't there doesn't mean
that the phpGW architecture needs to change.  InfoLog is a fine example
of pulling different modules' data stores into a single interface/app.

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

I disagree.  While the schema isn't perfect, I certainly don't see
copies of tables being made to be application specific.

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

Sure, but I wouldn't want to be the sucker to DBA it.  Especially
installed in alongside other apps outside of phpGW (which would be
common in Oracle installations or web hosting, for example)

Mike