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

[C K Wu]

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