Hi Robin!
I also agree with Rabus about the new requirements of PHP and MySQL (after 2.5.0).
Looks like we have a deal on that issue? ;)
+1 here as well, so I think it's a done deal.
Great. I'm really looking forward to the new abilities we're having with using more recent PHP/MySQL versions. :)
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!
Many thanks for that...that's making me blush. ;) Even though I think I haven't done too much special in comparison to all the effort you other guys put into this project, I really appreciate that. :-)
Agreed on the freeze date. My semester and final exams are over April 15th, so things get interesting after that ;-).
Maybe we all find a way to cooperate on the session-related rewrite off the code. :)
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.
Yes, I thought of something similar. Kind of a drop-in-replacement for the grab-globals. There are mainly a bunch of major variable like $goto and all those input-hidden fields we have to take care of.
If I understand Rabus correctly, we should all immediately use $_POST and the like superglobals and $_SESSION[] = 'XXX' session storage. I wonder, how much data we are willing to store in a session. I guess we'd have an advantage if we store the whole configuration into the session and thus overriding a lot of configuration parsing?
On which kind of session propagating should we focus? Make cookie neccessary, rely on PHP's automatic session propagating, or include own functions to make sessions work no matter if session_trans_sid is enabled? I guess if we take over the SID propagation on our own, we'd be on the safer side...?
I vote for dropping older support. This will make the code smaller and easier to maintain.
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.
Yes. I just had some "if PHPVERSION is >= 4000..." ... "else" construct in mind for PHP and MySQL, so we should drop all 'else' cases. Rework on critical workaround-functions should be applied were necessary.
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).
You don't mean 'full rewrite' as in 'full rewrite', don't you? ;)
Anybody up for starting a wishlist for the proper re-write of PMA3 ?
I'm more willing to shed some tears on the extensive amount of work that would take.
uses an HTML library (no raw HTML in the code) - MUCH cleaner
If we use that, we should go with PEAR. Adapt with PEAR coding style, put PEAR error handling in it and we could ponder whether to user PEAR:DB or even better PEAR:MDB. If we make a complete rework, we should do it right. But, as I said before and on the forum - I don't see an early success for that. :)
Regards, Garvin.