Hi Marc, Garvin & list, -----Original Message----- From: Garvin Hicking March 30th is to early for a RC since the nomerous new features need a lot of debugging now. A beta would be OK for me. I fully agree. Garvin, my A levels have highest priorety at the moment. Unfortunately, I have various exams ("Vorabitur") until April 1st. I won't have much time during this period. Furthermore, I have to tell you that my script is going to be PHP3 incompatible. I decided to go this way because the setup script is devided into several steps and I need sessions for passing information from one step to another. Imho, those few PHP3 users can still fill out their config file manually. Bug #697979 (the one that patch #701111 tries to fix) is a good reason why we should use sessions throughout the application. I remember some other issues that were caused by too long URIs. We can only work around such problems as long as we support PHP3, but not fix them. I am really tired of coding workarounds against old versions. The php development is running towards 5.0 and we are still supporting relicts of the last millennium... After the next release - whatever it will be named - we should think about phpMyAdmin's requirements. Currently we say: - PHP3 >= 3.0.8 (released about 4 years ago) with MySQL extension or PHP4 - MySQL >= 3.21.0 (released about 6 years ago), but < 4.1.0 My suggestions: - php >= 4.1.0 (Dec. 10th, 2001) php 4.1.0 introduced the superglobal arrays that make session management and accessing HTTP request variables as easy as it is now. This version is dated December 10th, 2001. I think, this is old enough. - MySQL >= 3.23.32 (Jan. 22nd, 2001) MySQL 3.21.0 is more than 6 years old! Do we really need to support this relict? Even the MySQL manual says, "Version 3.21 is quite old now, and should be avoided if possible". The same for 3.22.x: This branch has already been marked as "discounted" by MySQL. MySQL 3.23.32 is the first MySQL 3.23 release that is marked a stable. Yesterday, I visited CeBIT in Hannover and talked to some MySQL guy about MySQL 4. He told me that the MySQL 4.1 binary distributions should be released this month. So with a little bit of luck and time - I don't know how deep I'll have to go into the code - we could support MySQL 4.1.0, soon. :-) Before you refuse my suggestions, please note the following: It is not that PHP3 and MySQL 3.21 users suddenly aren't able to use phpMyAdmin anymore. There are still the old releases which are functional and stable enough. I cannot imagine, that a user being content with PHP3 an / or MySQL 3.23 wants to use phpMyAdmin's latest new features. Furthermore, did anyone of you test phpMyAdmin 2.4.0 with PHP3 or MySQL 3.21? Is anyone of you able to do so? Finally, please just have a look at our download statistics for 2.4.0: - php files: 76,065 downloads / 93.2 % - php3 files: 5,533 downloads / 6.8 & Regards, Alexander M. Turek &lt;alex(a)bugfixes.info&gt; +-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus(a)users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus(a)bugfixes.info | +-----------------------------+

Garvin Hicking wrote: I also agree with Rabus about the new requirements of PHP and MySQL (after 2.5.0). So the new version will be 2.5.0. Indeed I had mentionned this renaming to Garvin (or the list?) a few days ago. Instead of talking about rc1, I should have said "feature freeze". We have to freeze someday :) So do we freeze on March 30? About Sessions, I agree but I would prefer that the rewrite goes gradually into the tree, instead of a rewrite that stalls other developers. So we split the rewrite between developers? About PHP3 and older MySQL, do we let the current workarounds in place? I say yes, would be a big job to remove them. But we no longer put workarounds for new debugging/features. Finally, phpMyAdmin 3.0 should be in a distinct branch, and the code would be .php based. Marc

On Mon, Mar 17, 2003 at 01:31:10PM +0100, Garvin Hicking wrote: +1 here as well, so I think it's a done deal. On seeing the impressive new feature list, I would like to extend a special thanks to Garvin. The amount of work he's put into this over the last little while is a sizeable contribution to PMA. Someday when I'm in Europe I'll buy you a beer! Agreed on the freeze date. My semester and final exams are over April 15th, so things get interesting after that ;-). I think that the session rewrite shouldn't be too intrusive if done properly. I've been playing around with a little idea for a session hack already that should be possible to drop into PMA. It's all based around knowing what values of variables get set where, and having a complete list of variables at each entry and exit point of the code. However having two seperate branches, one for all other features, and one for the session rewrite may come in handy for working on it still Lets be careful about this. Some of the workarounds exist literally as workarounds, but some of the other code (such as my SQL parser) was written with PHP3 in mind, and if redone, could radically benefit from pure PHP4. In CVS terminology, I think PMA3 should be a new module 'phpMyAdmin3' rather than just a branch of the code. It should definetly be a full rewrite of PMA from the ground up, with additional consideration given to which PHP modules will be available in the PHP version we choose (4.xx). This will enable us to keep the old 'phpMyAdmin' module intact in CVS as well for major bugfixes to it. Anybody up for starting a wishlist for the proper re-write of PMA3 ? my initial requests: uses an HTML library (no raw HTML in the code) - MUCH cleaner easier to manage translations system - using gettext (see Horde) install script db-based config -- Robin Hugh Johnson E-Mail : robbat2(a)orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Do we have any statistics as to what percent of sites are using an older version of PHP? Brendan

Hi Rabus! Fine for me. 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. :-( ) 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.

Rabus a écrit: Hi all, Are we feature frozen? :) Marc