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.