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 uml d oc


From: Dave Hall
Subject: Re: RE: [Phpgroupware-developers] Re: phpGroupware database and uml d ocumentation in wiki?
Date: Fri, 13 Jun 2003 18:37:32 +1000

Kai Hofmann <address@hidden> wrote:

> 
> > -----Original Message-----
> > From: Dave Hall [mailto:address@hidden
> > Sent: Friday, June 13, 2003 2:36 AM
> 
> > One minute you wish to have an open discussion then you send the
> > proposal to a select few, with a request to not publish it.  
> > I am confused.
> >
> > I do not understand the licensing issues.  As it currently 
> stands all
> > apps in the phpgw cvs are distributed under the GPL.  This schema
> > impacts on all phpgw apps, and there components of the model which
> > affects a GPL'd app, so I fail to see what the licensing issues are.
> >
> > So I do not see why this document can't be added to the wiki 
> 
> The database model I send is completly independend of the 
> phpGroupware -
> it is another probusiness internal project - and I got permission 
> to send
> it to some people as an example how the phpgroupware db could look 
> like -
> to make clear about what we (at probusiness) are talking about.

This was not clear in the email, that is why I queried it ... it did
look like a HR, CRM, projects model for phpGW when i looked at it.

> 
> > I think we can all understand db modelling.
> 
> I have received answers that tell me that "this theoretical stuff 
> is not
> understandable". So I explained this.

Ok, some people may benefit from this, but from my understanding of the
skills of the people you chose to email they would have no issue with
understanding the model - if the purpose of it was explained.

> 
> > This actually appears to me to be some type of confused model which
> > attempts to do HR and CRM in one model.  Unfortunately phpGW is
> > groupware which should have some CRM functionality (through 
> > infolog) and
> > basic HR functions (through reworked contact> not trying
> > to do everything possible for every situation.
> 
> 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.

> You only have
> different applications which are trying to interact by another one
> (infolog).

No this is not true.  Infolog is one what which pulls together a lot of
data, hence its name.  But many apps utilize the contacts classes in the
API.  The issue is that all phpgw apps should be able to exist with only
API, prefs, and admin apps, without having a compulsory dependency on
antoher app.

> 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.  If
you desire complete integration then something like PHProjekt
(http://phprojekt.org/) is probably more suited to your needs.

> Infolog is a great thing - but it should be there only 
> for the
> user interaction.

Yes and no.  Infolog is a great app.  My primary client does not use it
(ralf will hassle me about that ;) ), but they use contacts for tight
data integration ... as that is part of the api.  How the user interacts
with the an app is up to the developer, and all apps should not depend
on any other app, other than the api, where ever possible ... imo

Cheers

Dave

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


reply via email to

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