[Top][All Lists]

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

Re: [Phpgroupware-users] Anouncement: eGroupWare fork of phpGroupWare

From: Dan Kuykendall
Subject: Re: [Phpgroupware-users] Anouncement: eGroupWare fork of phpGroupWare
Date: Fri, 05 Sep 2003 13:48:05 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2

R B wrote:

   It's good to have varieties but I hope
phpgroupware &  egroupware are not going to turn into
phpnuke/postnuke/evolution/etc with apps having
problem   working in each other. The developers are
having nightmares trying to write code to conform to
all of them (well at least the major forks anyway). To
the users, there are not much different between them.
Just bugs are slower at getting fixed due to scattered
of resources.
  I wish phpgroupware/egroupware will not have that
sort of problem.

I dont think there will be the same situation. The reason is that phpGW and eGW are going to likely move in radically different directions and there will be no intent from my to maintain any sort of compatibility.

  As a normal user, I would like to make a suggestion
(even it may seem stupid). Maybe I've been missing the
point but from what I've seen is that phpgroupware and
egroupware have two different business model.

This is only one of the diffs. There is a diff of vision as well

Technically, the two are still the same - ie. the
underlying architecture is still the same - then why
not have a central group that coordinate the
developement of the core structure, much like the
Linux Kernel.
For the moment the code is shared, but as things progress they will become far too different for something like this.

For example, I think they will intend to have eTemplates drive the interface of eGroupWare and the apps for it. This makes perfect sense from their side, since Ralf (one of the forkers) has spent a lot of time developing eTemplates into a nifty solution. However, I do not think eTemplates will work as well as they do, and we will be moving to an XML and XSL solution. All the apps will be focused on generating XML results which will be processed by either the browser or PHP's xslt support (depending on browser detection).

This is only one example of the fundimental diffs that are going to keep things moving apart rather quickly.


reply via email to

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