[Phpgroupware-developers] phpGW NetxtGen and further development path

[Christian Boettger - Mailings]

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.

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.

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 ...

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).

OK, and now for the log of the IRC discussion... read it, think about it and
comment it.

March 31st 2004
[00:15:35] < Seek3r > skwashd: also, you mentioned you had some issue with
the new framework... I think you said it was with the dev method or
something like that
 [19:35:35] < Seek3r > so now on to your problem with the new framework dev
model
 [19:35:40] < skwashd > :)
 [19:35:57] < skwashd > i have some issues with the way the experimental
stuff is being done
 [19:36:15] < skwashd > also getting n00b who just want to get 16 working
being told to grab experimental
 [19:37:02] < skwashd > i think it should be a community discussion ... not
a couple of people deciding what we will be stuck with post 1.0
 [19:37:05] < Seek3r > the only reason I asked the n00b to get the
experimental was to see if its setup would work better
 [19:37:45] < Seek3r > things are open to the community... but so far only a
few are contrbuting ideas
 [19:37:55] < Seek3r > but I have talked with many in the project
 [19:38:06] < skwashd > yes ... cos we have been focussed on getting 16 then
18 out
 [19:38:10] < Seek3r > hell, I talk with anyone who will listen, in order to
drive attention and ideas
 [19:38:33] < Seek3r > so we should sit around and wait and have no proof of
concepts?
 [19:38:35] < skwashd > it diverts attention from what should be the real
focus ... getting head stable and out
 [19:39:34] < Seek3r > thats your opinion, and thats valid for you. But I
dont think the existing codebase is good enough, and that until the nextgen
is out, we will be playing catchup
 [19:39:54] < Seek3r > so I think that one of the most important things to
be done is get the new codebase moving
 [19:40:15] < Seek3r > I know thats my opinion, and that many dont care
about the new code
 [19:40:29] < Seek3r > so thats fine, and I leave them alone
 [19:41:13] < Seek3r > also, I thought stable was released a little while
ago
 [19:41:19] < Seek3r > so what stable are you talking about?
 [19:42:11] < skwashd > 16 was released
 [19:42:19] < skwashd > we still have head
 [19:42:23] < skwashd > which is a mess
 [19:43:12] < Seek3r > so thats not "stable"
 [19:43:20] < Seek3r > you released .16
 [19:43:34] < skwashd > 16 != head
 [19:43:52] < Seek3r > yes, and so HEAD != stable
 [19:43:58] < skwashd > yes
 [19:44:02] < Seek3r > above you said that focus should be on getting stable
released
 [19:44:28] < skwashd > <skwashd> it diverts attention from what should be
the real focus ... getting head stable and out
 [19:45:20] < Seek3r > head and stable?
 [19:45:29] < skwashd > no ....
 [19:45:30] < Seek3r > because head is not stable
 [19:45:34] < skwashd > getting head stable
 [19:45:40] < Seek3r > out
 [19:45:41] < Seek3r > oh
 [19:45:42] < Seek3r > ok
 [19:45:46] < Seek3r > well, I disagree
 [19:45:54] < Seek3r > I think the code in head is a waste and pointless
 [19:46:29] < skwashd > who is going to port the code to experimental then?
 [19:46:38] < Seek3r > everyone that wants to
 [19:47:01] < Seek3r > and anyone who wants to continue with HEAD is
perfectly OK to do so
 [19:47:10] < skwashd > i think you will find there are more people who are
committed to getting head stable ... than working on experimental
 [19:47:23] < Seek3r > why would that bother me?
 [19:47:34] < skwashd > i am not saying it should
 [19:48:02] < skwashd > but i do object to building support for experimental
before head is relatively stable
 [19:48:05] < Seek3r > and why does it bother you if I gather some who want
to work on experimenal?
 [19:48:16] < skwashd > cos we should be focussed on head
 [19:48:17] < Seek3r > why? what if others agree with me?
 [19:49:07] < skwashd > ok ... lets throw months of work out the window
 [19:49:11] < Seek3r > for those others like me who think head code is a
complete useless mess... I give them exciting new code to work with
 [19:50:16] < Seek3r > throwing more time into a bad set of code is not
always the answer either
 [19:50:36] < skwashd > then develop a clear migration plan
 [19:50:47] < skwashd > porting guidelines
 [19:50:52] < skwashd > dev docs
 [19:51:10] < skwashd > develop the infrastructure to support the move
 [19:52:39] < Seek3r > thats the wrong approach
 [19:53:32] < skwashd > what is the wrong approach?
 [19:53:45] < skwashd > making the move easy?
 [19:53:46] < Seek3r > we need to not worry about porting issues right now.
We need to focus on building the "right" design
 [19:53:54] < Seek3r > we can build the porting scripts later
 [19:54:30] < skwashd > ok ... so just you and jengo can develop the best
design?
 [19:54:37] < Seek3r > no
 [19:54:43] < Seek3r > anyone can participate
 [19:55:20] < Seek3r > we have gotten contributions from many
 [19:56:02] < Seek3r > mdean, lex, fixe, dan cech and ceb have all throw in
ideas and discussed the design in detail
 [19:56:32] < Seek3r > so far only jengo and I have written code
 [19:56:38] < Seek3r > but we use everyones ideas
 [19:58:14] < Seek3r > I have discussed specific app issues with a few
others in here, and they have provided interesting ideas for the apps as
well
 [20:01:05] < Seek3r > I am obviously looking for people to contribute
 [20:01:18] < Seek3r > I am in here often and talk about it with anyone
interested
 [20:01:35] < Seek3r > I want others to contribute to the design and to the
implementation
 [20:02:14] < Seek3r > I could obviously go and just take the code as
another project name and start everything new
 [20:02:51] < Seek3r > but I think its better to give this project the best
of both worlds
 [20:03:07] < Seek3r > we have development going on in a stable and well
known product
 [20:03:37] < Seek3r > and we have a new codebase working from a new vision
of how to build things... similar, but also very different
 [20:03:58] < Seek3r > the new code is fresh and exciting, the old code is
worn and tested, and is a fine product
 [20:04:17] < Seek3r > so we can provide people involved and interested in
the project with the best of both worlds
 [20:04:29] < skwashd > i have no problem with trying to develop a better
code base
 [20:04:33] < skwashd > it is how it done
 [20:04:51] < Seek3r > and how *should* it be done?
 [20:05:11] < skwashd > yes
 [20:05:11] < Seek3r > I scratched an itch, and wrote the code... should I
not conrtibute it to the project?
 [20:05:32] < skwashd > i am not saying that
 [20:05:50] < skwashd > i am talking about where we have agreed the focus
should be 
 [20:06:09] < Seek3r > I dont think there is any agreement on that
 [20:06:17] < skwashd > isn't there?
 [20:06:34] < Seek3r > I do not agree to focus on the 0.16 or head code...
Im not interested in it
 [20:06:58] < skwashd > agreement != consencus
 [20:07:13] < Seek3r > I think the longer we waste on the head code, the
futher we get behind the competition
 [20:07:57] < skwashd > anyway .... i have to prepare some quotes
 [20:08:03] < Seek3r > but I also understand that many need the current code
for business and use for today
 [20:08:21] < Seek3r > so I do see the reason for .16
 [20:08:30] < Seek3r > but head is such a mess, and I think will take a year
to get ready
 [20:08:42] < Seek3r > and so I think head is a distraction from what really
needs to be done
 [20:10:05] < Seek3r > you still havent said how it should have been done...
I would like to know that, because I did it the best way I knew how. so if
you had a better way, I would learn from that
 [20:10:38] < Seek3r > Ive gone to the extent of writing journals of the
progress and ideas
 [20:10:53] < Seek3r > have written the setup prog to make it easy for
anyone to install and experiment
 [20:11:05] < Seek3r > have setup a demo, to show those that dont even what
to install
 [20:11:13] < Seek3r > write docs on the ideas for the apps
 [20:11:36] < Seek3r > and I come in here and chat with people for ideas and
to get people educated on what we are doing

April 1st 2004
[00:55:23] < bofh42 > Seek3r: i do understand the reasons behind a new
framework
 [00:56:18] < bofh42 > but stopping development of head would mean that we
would leave the users alone for a very long time
 [00:56:51] < bofh42 > the new framework might be 80% ready in 8 months
(even that i doubt), but that's only the start of the real work
 [00:57:11] < bofh42 > as there is no migration path, it would just be a
framework with a few core apps
 [00:57:50] < bofh42 > and not a full phpGW with all the features it has now
 [00:58:36] < bofh42 > and having a wide variety of applications is what
makes phpgw attractive
 [00:59:03] < bofh42 > so basically we would disappear from the market for
years
 [01:00:23] < bofh42 > another point: it's true that you can't port old apps
to the new framework now. but it's not true that we can care about that
later. there has to be some sort of migration path later on.
 [01:00:52] skwashd hands bofh42 the steel capped boots
 [01:00:56] < skwashd > ;)
 [01:01:14] < bofh42 > so there has to be concept of how that can be
accomplished from the start. otherwise it will be a big mess to squeeze it
in later, if not even impossible
 [01:01:33] bofh42 smirks
 [01:02:51] < bofh42 > so we run the danger of ending up with two
incompatible projects under the same name
 [01:03:11] < skwashd > bofh42: that sounds like windoze xp ;)
 [01:06:42] < bofh42 > windoze?
 [01:07:26] < skwashd > M$ windoze
 [01:07:43] < bofh42 > sure, but what sounds like windoze?
 [01:08:46] < skwashd > <bofh42> so we run the danger of ending up with two
incompatible projects under the same name
 [01:08:51] < skwashd > :)
 [01:09:03] < bofh42 > e.g. if it would be possible to have old apps and the
new framework co-existing under some sort of portal, transparent for the end
user, that would help

[01:53:35] < Seek3r > bofh42: I understand your points
 [01:54:10] < Seek3r > As far as being out of the market for a long time...
it took 18 months to get .16 out, thats a very long time
 [01:54:26] < bofh42 > way too long
 [01:54:34] < Seek3r > and I think HEAD will do that again
 [01:55:05] < bofh42 > hopefully not
 [01:55:08] < Seek3r > and it will be for very little gain... just
incremental... in the same period I feel we could have something in a large
magnitude better
 [01:55:19] < Seek3r > by using the new framework
 [01:55:41] < Seek3r > now thats my opinion on that part of the issue
 [01:55:53] < bofh42 > i'm not sure. porting all the apps would take much
longer
 [01:55:57] < Seek3r > others feel like its worth continuing, and I am not
going to try and stop them
 [01:56:27] < bofh42 > ideally we could enhance HEAD and use it for releases
+ develop the new framework. if we only had enough developers
 [01:57:03] < bofh42 > what about the portal idea as a migration path?
 [01:57:18] < Seek3r > as far as the porting issue... I simply am not going
to worry about that until we know what the ideal new framework needs to be,
and I will not burden its design just to accommodate backward compatibility 
 [01:57:45] < Seek3r > once we have it worked out to be what we want, then I
will put more serious thought into the porting issue
 [01:58:07] < Seek3r > the portal might work... just depends
 [01:58:20] < bofh42 > in a year or so? how can i explain to our customers
that they have to wait another year?
 [01:58:22] < Seek3r > the thing is that the current code allows apps to
output data
 [01:58:44] < Seek3r > why cant current user needs be met by .16 and some
improvements to that codebase?
 [01:59:01] < Seek3r > in the new framework, apps are not allowed to output
anything
 [01:59:06] < skwashd > Seek3r: cos 16 is 14 with improvements
 [01:59:17] < bofh42 > well, yes; unfortunately
 [01:59:21] < skwashd > Seek3r: that is also the idea for head ... no more
echos
 [01:59:22] < Seek3r > the app methods just return an array or xml, but they
cannot "echo" anything
 [02:00:08] < Seek3r > well, thats a massive amount of "porting" work
 [02:00:28] < Seek3r > that sort of effort is a big part of porting to the
new framework
 [02:00:52] < Seek3r > the other is to use safe_args in each of the
functions
 [02:01:08] < Seek3r > I think those are the two biggest issues in porting
 [02:01:48] < bofh42 > all true
 [02:02:04] < Seek3r > oh, and apps no longer are able to have their own
pages that users would be pointed to... such as email/compose.php
 [02:02:17] < Seek3r > there is only one point of entry, and that is the
main index.php
 [02:02:48] < skwashd > Seek3r: that is good design anyway
 [02:02:57] < Seek3r > right
 [02:03:12] < bofh42 > a .18 will have to be a sort of "merge" (not cvs
merge) of .16 and HEAD. but .16 apps will still have to work in co-existence
 [02:03:17] < Seek3r > the other porting issue, is the switch to adodb
 [02:03:19] < skwashd > also desiging it so only index.php is in the docroot
should be a requirement
 [02:03:35] < Seek3r > but even that is pretty minor, since we still have a
$db->query function
 [02:03:42] < Seek3r > oh well, I take that back
 [02:03:47] < Seek3r > the way you retrieve the results is diff
 [02:04:16] < Seek3r > skwashd: you mean no login.php and logout.php?
 [02:04:22] < Seek3r > we did that in the new framework
 [02:04:28] < skwashd > Seek3r: no ....
 [02:04:43] < skwashd > so it is designed to live out of the docroot ...
except index
 [02:04:47] < skwashd > so you have ....
 [02:04:57] < skwashd > /var/www/phpgw/index.php
 [02:05:04] < skwashd > /usr/local/phpgw/
 [02:05:20] < Seek3r > hmmm, thats a good point. I havent done that yet
 [02:05:23] < skwashd > /usr/local/phpgw/ contains all the scripts/classes
 [02:05:42] < Seek3r > would be an easy thing to add to the new framework
 [02:05:43] < skwashd > oh ... and you will need 1 other file ....
 [02:05:49] < Seek3r > might do that right now as an experiment
 [02:05:58] < Seek3r > would need index.php and config.php
 [02:06:25] < skwashd > config.php ... which just contains a simple check if
it is included or called directly ... which calls config.php in /usr/local
 [02:06:51] < skwashd > if it is called directly ... error and email the
error
 [02:07:24] < Seek3r > well, for soap and xmlrpc they would also need the
soap.php and xmlrpc.php files
 [02:07:46] < skwashd > ok ... so 4 files
 [02:07:59] < Seek3r > those are like index.php but set the interface type
for the api.... I have considered doing some detection, but havent gotten to
that yet
 [02:08:18] < skwashd > which could even just be a symlink back to
/usr/local/phpgw/docroot/ :)
 [02:09:41] < bofh42 > i would still like this specific discussion been
forwarded to the mailing list ... 
 [02:09:51] < skwashd > bofh42: so would i
 [02:10:04] < skwashd > i think any design discussion should happen on the
dev list
 [02:10:31] < skwashd > with a clear disclaimer ... that is it for post
0.9.18.001 (which will become 1.0)
 [02:11:02] < Seek3r > skwashd: I have always been open about talking about
this on the list, and think I have sent a couple out about it
 [02:11:18] < Seek3r > just havent gotten much response, so I just continue
plugging away
 [02:11:27] < skwashd > Seek3r: yes ... but the adodb change ... that was
just you
 [02:11:36] < Seek3r > I also think I will have a version of this codebase
ready for a first release, before head is released
 [02:11:42] < skwashd > none of the big changes have been discussed
 [02:11:47] < Seek3r > skwashd: was jengo and I, correct
 [02:12:10] < skwashd > you == you 2 // in this context :P
 [02:12:13] < Seek3r > its experimental code... and phplib db classes and
schema_proc dont cut it anymore
 [02:12:29] < Seek3r > afk for a few
 [02:12:57] < bofh42 > so any objections if a copy of this goes out to the
mailing list?
 [02:13:09] < skwashd > bofh42: not from me
 [02:13:20] < skwashd > my position is pretty clear :)
 [02:13:43] < Seek3r > none at all
 [02:14:10] skwashd gets his steel caps ready for the list ;)
 [02:14:15] < skwashd > smoko
 [02:14:27] < Seek3r > as far as adodb.... again its to the point of looking
at this with the mindset of taking this chance to build this as a best of
breed solution, and not to just continue doing things as we do them now,
because thats what we do now
[02:17:53] < skwashd > back
 [02:18:53] < skwashd > Seek3r: i do not object to using adodb ... but
consultation is needed ... it is not only you and jengo who have idea ... or
you 2 will not be the only ones coding on it
 [02:19:31] < skwashd > s/idea/ideas
 [02:24:20] < Seek3r > back
 [02:25:19] < Seek3r > who should we ask, and who should get to decide about
the code that only use two are actually writing?
 [02:25:50] < Seek3r > I announced it quite loudly
 [02:25:57] < Seek3r > even talked to mdean about it
 [02:26:17] < Seek3r > anyone that has an issue with that, is free to speak
up
 [02:27:16] < Seek3r > if I sit around and wait for each decision to be
debated on the mailing list, when few are paying attention, and there is
such delay
 [02:27:20] < skwashd > you announced the adodb change?
 [02:27:24] < Seek3r > it will take forever to make progress
 [02:27:42] < Seek3r > I didnt on the mailng list, but I was in here talking
about it
 [02:27:57] < Seek3r > and I posted it in the dev journal for the new code
 [02:28:04] < skwashd > Seek3r: we all have to consult and wait ... that is
the cost of democracy ... the advantage ... more poeple have input
 [02:28:29] < Seek3r > thats fine for the current code, but not for the
experimental stuff right now
 [02:28:36] < Seek3r > its moving way too fast for that
 [02:29:05] < Seek3r > if anyone had shown interest, I would open up more
for discussion
 [02:29:10] < Seek3r > I have no problem
 [02:29:19] < Seek3r > but I havent gotten much interest yet
 [02:29:37] < skwashd > ok ... i think you should start a new cat on the
forum ... nextgen - post 1.0 development
 [02:29:38] < Seek3r > so we just plug away and figure it will come as
people can see more and use it more
 [02:29:47] < skwashd > and allow people to get involved there
 [02:29:57] < skwashd > link to it from the nextgen site
 [02:29:59] < Seek3r > yuck, I hate cats
 [02:30:09] < Seek3r > maybe a new mailing list nextgen-dev
 [02:30:17] < Seek3r > I mean, I hate forums
 [02:30:31] < skwashd > ok ... what ever ... something that people can opt
into
 [02:30:33] < bofh42 > perhaps use the new open wiki?
 [02:30:40] < skwashd > fine with me
 [02:30:52] < skwashd > bofh42: good idea
 [02:30:58] < skwashd > i need to test it a little
 [02:30:59] < skwashd > :)
 [02:31:40] < Seek3r > skwashd: btw, moving the files out of the docroot
doesnt work for the new framework, because it would break offloading xslt
rendering to the browser
 [02:32:09] < Seek3r > because the xsl files are in the
appname/skins/skinname dirs and the browsers read them directly
 [02:32:13] < skwashd > Seek3r: then keep the xslt in the docroot
 [02:32:42] < bofh42 > Seek3r: what about the wiki instead of a forum cat?
 [02:32:46] < Seek3r > and its also not a problem to have the rest of the
files in the docroot... they are all only class files, and dont "do"
anything without something to execute them
 [02:32:56] < skwashd > it is usually better design to keep scripts which
don't require direct access out of the docroot
 [02:33:05] < Seek3r > bofh42: I have never personally used a wiki... but I
dont mind experimenting
 [02:33:43] < bofh42 > :-) perhaps it's a good time for such an experiment
now
 [02:33:52] < skwashd > Seek3r: feel free to play on it ... it is on my box
... so i can rollback any changes you don't want to keep in the history :P
 [02:37:04] < Seek3r > what im not sure about is which is better for
discussion. I thought wiki's were mostly good for generating documentation
 [02:37:59] < bofh42 > yep... but you can as well open a page for a topic
and gather ideas there. and re-work them easily
 [02:39:31] < Seek3r > so users can post their comments easily, in a way
where they are not just editing others?
 [02:39:40] < bofh42 > a wiki can't easily trace the flow of a discussion,
but it can keep the results
 [02:40:06] < bofh42 > they can just add text, e.g. below the original text
 [02:40:31] < Seek3r > so maybe we should stick to mailing list for the
discussion, and then move to the wiki as we have some more flushed out
ideas?
 [02:41:03] < Seek3r > I really dont know much about wiki's so its hard for
me to say which is better in this case
 [02:41:44] < Seek3r > I am used to email, but given the fact that the new
framework is all about new ideas, new approaches and pushing us to a new
level... I suppose I can try something new as well
 [02:42:03] < bofh42 > for a pure discussion, a forum or a mailing list (or
better a NNTP server) is better than a wiki, but for keeping results a wiki
is better
 [02:43:14] < Seek3r > how do I use this wiki? I see no option for creating
new pages and such
 [02:44:16] < bofh42 > wait a minute
 [02:52:29] < bofh42 > http://tavi.sourceforge.net/FormatierungsRegeln
should work
 [02:53:00] < Seek3r > works, but I cant read it
 [02:53:01] < bofh42 > ops, sorry:
http://tavi.sourceforge.net/FormattingRules
 [02:53:09] < Seek3r > heh
 [02:53:38] < Seek3r > who's wiki is this?
 [02:55:05] < bofh42 > that's the original WikkiTikkiTavi project, which has
been included in .16

 [03:06:39] < Seek3r > does this have accounts, and the ability to lock
certain pages from anyone being able to edit them?
 [03:08:48] < Caeies > I don't understand why people want to lock wiki pages
:/
 [03:09:27] < Seek3r > I would think that sometimes it would be useful
 [03:09:41] < Seek3r > I dont know.... as mentioned, I have never used a
wiki before
 [03:12:24] < Caeies > I know that people want to lock pages
 [03:12:38] < Caeies > but Taht's not in the wiki philosophy :)
 [03:14:25] < Seek3r > well, I would think I would require it... so Im
guessing some have added such a thing
 [03:16:58] < bofh42 > well, if bad things happen, the admin can always roll
back the page.
 [03:18:07] < bofh42 > but even the wikipedia doesn't really need that (no
locking there) http://www.wikipedia.org/
 [03:20:17] < Seek3r >
http://wiki.phpgroupware.homelinux.org/index.php?page=nextgen
 
Regards

Christian aka bofh42

-- 
Dr. Christian Böttger
Leiter Softwarelösungen
pro|business AG
DEUTSCHER PAVILLON
EXPO Plaza 1
30539 Hannover
Tel.: 05 11 / 6 00 66-331
Fax: 05 11 / 6 00 66 -355

e-mail: address@hidden
Internet: http://www.probusiness.de/
*****    Open Source und Linux im professionellen Einsatz    *****
**  komplexe Mailserver, Groupware, Office: sprechen Sie uns an **