Hi Rabus!
In this case, I'd propose the following:
- April 6th: Feature freeze
- April 13th: 2.5.0-rc1
- April 27th: 2.5.0-rc2 (We probably need 2 RCs)
- May 11th: 2.5.0 (if necessary 2.5.0-rc3)
- May 18th: alternative release date for 2.5.0
Fine for me.
After the release of 2.5.0, we rename all *.php3 files to *.php and create a 2.5.x branch. Rewriting all libraries for session support will probably take a little longer, so branching would be the best solution. The version number of the 2.5.x branch will be incremented to 2.5.1-dev, the HEAD one to 2.6.0-dev or 3.0.0-dev, whatever you want.
I also like that idea. The more I think about Robin's suggestion for a full rewrite, the less I'm motivated by it. I think we should smoothly expand the current sourcecode. First step would be to implement session usage where we want it to have. Definitely for propagation of the $goto and $sql_query, as well as the $language variable. Variables like $db and $table should be passed by GET/POST, so allow bookmarking and so on.
We should also use Sessions for authentication and for the config.inc parsing. I don't think we should put blob or mysql data into sessions, to maintain a multi-user environment and not being screwed when the table has changed and you still work with session representations of the table.
After we have gotten the sessions to work, we could get a grip on removing all those PHP3/MySQL 3.22 workarounds and maybe optimize some portions to PHP4 syntax/OO style, if useful. Maybe we can rewrite whole passages here, if necessary.
Then we should think about using and integrating a template class. We definitely need a powerful template classe (not the PHPLibs one) for many nested subsets and optional parsing of seperate blocks. Just think of the whole 'if $cfgRelation[xxxworks]' clauses where we have to create a seperate template block or even a whole new template file every time. I haven't got a look to Smarty, put it seems powerful.
When implementing the template system, we should CSS-cleanup the code. Remove style attributes and replace everything with classes. Maybe we find some other non-strict XML constructs which can be dropped as well.
After those three steps, we'll have a pretty lean application... let's do it. *g*
In the end of May I will be finished with my education, so I'll have more time after that and less the next two months. I hope I will be able to contribute a lot to this rewrite. Dropping the whole 'every time authentication and config.inc parsing and so forth' constructs should give us a pretty speed improvement. :-) (which may be completely wasted by using templates, BTW. :-( )
- a library of abstract functions for most common MySQL operations. This
would allow us to implement feature #572725 for instance. I know that this one has been rejected, but it won't be that hard to support other SQL dialects as long as we create seperate libraries for them as we do with the authentification modes. I don't want to go that far and support non-SQL DBS' either.
I agree. We should really evaluate, if we can go with PEAR:DB or PEAR:MDB. XML-based storage could be great on MDB...
Regards, Garvin.