phpgroupware-developers
[Top][All Lists]
Advanced

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

RE: RE: [Phpgroupware-developers] Re: phpGroupware database and u ml d o


From: Kai Hofmann
Subject: RE: RE: [Phpgroupware-developers] Re: phpGroupware database and u ml d ocumentation in wiki?
Date: Fri, 13 Jun 2003 11:23:45 +0200

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.
The data is important for a groupware because a groupware
integrates data instead of having a single application for each
work process.

> > 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 - which task is to maintain the db api
   as well as the "central db-schema" (in cooperation with the module
mainatiners).

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

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

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

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!


Greetings

   Kai

-- 
*****    Open Source und Linux im professionellen Einsatz    *****
**  komplexe Mailserver, Groupware, Office: sprechen Sie uns an **
Dipl.-Inform. Kai Hofmann                    Team Softwarelösungen
pro|business AG, EXPO Plaza 1 (Deutscher Pavillon), 30539 Hannover
E-Mail: address@hidden,   Tel.: 0511/60066-332, Fax: -355
WWW: http://www.probusiness.de/




reply via email to

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