R B wrote:
G'day,
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.
Dan
|
