phpgroupware-developers
[Top][All Lists]
Advanced

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

Re: [Phpgroupware-developers] phpGW NetxtGen and further development pat


From: C K Wu
Subject: Re: [Phpgroupware-developers] phpGW NetxtGen and further development path
Date: Thu, 01 Apr 2004 21:30:19 +0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030

Hi, folks,

Being an add-on (CK-Ledger) developer and not a real user of phpGroupWare,
my opinion is definitely biased. I would side with Dan in this case, based on the simple fact that phpGroupWare really has to catch up with the rest of the field. A lot of the other post-nuke, wiki, forum variants that run on LAMP had already surpass phpGroupWare, in terms of quality of design, ease of administration, etc...

NextGen hopefully fast tracks phpGroupWare back on par with the others.
My plan with CK-Ledger is to switch to NextGen, as soon as a stable release
is available.

The thing to consider is perhaps data migration path for existing users. However,
with the data sync classes that were being developed, perhaps we can provide
a simple frontend for the two way sync between a phpGW1.0 and
phpGW2.0 installation.  The users can then perform the two way sync if and
when he/she is prepared to migrate.  Behind the scene, 0.9.18 and NextGen
could be developed in parallel.

Just my 2 c.

Cheers,
CK


Dan Kuykendall wrote:

Christian Boettger - Mailings wrote:

Hi,

sorry for the log text that follows, but ... well, some things can't be said
in a few lines.

There has been a discussion about the way to go with phpGW in the near and far future on our IRC channel #phpgroupware on FreeNode. We agreed that this
discussion is of wider interest, so I'm posting it on this list as well.

Currently there are two development tracks, as far as I understand:

1) make the HEAD branch stable and branch a stable 0.9.18 (which should
become phpGW 1.0) from that, including all the new features that showed up in .16 (but are not in HEAD). Or, from another point of view: take .16 and include all the HEAD features, e.g. XSLT support). This has to be done soon and it is quite an effort, so we really appreciate any help; especially from
the app maintainers who maintain apps in .16

Im my view, this has to be a main focus at this time.


As far as the HEAD code, there are some things from NextGen that can be back ported which if everything starts using in the HEAD code, it will make later migration easier.

2) start all over again with Dan's new framework called NextGen. His
timeframe is ambitious, and it will definitely take some time. Currently
there is no migration path for existing apps and only core apps are worked on, but on the other hand the concept behind it is much better designed than
the current code. Me personally would not have choosen php for that (but
Java or .NET/Mono/dotgnu), but that is a different discussion.

>
> This is an approach for a phpGW 2.0, I guess.
>

Its not really a matter of starting over. Large chunks of code will be able to move over. What will be a bit hard to to take an app and just drop it in and have it work. The NextGen framework forces cleaner design, and forces html UI to be done with XSLT. There is no support for having things mix and matched as in the HEAD code.

Well, whatever: the question is: how can we get both a good basic structure and as well a continous development for the existing user base? Mind you, we
don't have hundreds of developers ...


This is a good point, and possibly one of the big concerns.
I would argue that we shouldnt worry about this all too much right now, and here are my reasons:

1) So far, those who are working on the NextGen (jengo and I) would not work in HEAD anyways, because we dont feel like dealing with the mess.

2) NextGen may attract new people into the project, because its new and exciting code. It offers loads of potential to a larger number of people.

3) Those that need something *now* will not be involved with NextGen, and will handle the HEAd code and ignore NextGen as they see fit.

Anyway, my personal wish would be to combine the best of both worlds
(perhaps in a sort or portal solution where both things can co-exist and
migration can be done stept by step).


Eventually we will create a migration path for users, and a basic porting doc for app developers. Upgrading the tables and such, should all be easy, but there will be lots of work involved to port an app, because its not really something we can automate.

I have put in a bit of work to get all the stuff I have for the NextGen into the new wiki. Its at:
http://wiki.phpgroupware.homelinux.org/index.php?page=nextgen

Seek3r


_______________________________________________
Phpgroupware-developers mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/phpgroupware-developers








reply via email to

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