[Phpmyadmin-devel] 2.4.1 release schedule

[Garvin Hicking]

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.