phplib-users

[Phplib-users] Current PHPLIB development questions

[Richard A. <rh...@ju...>]

I'm seeing all this traffic on the list about ongoing development to
PHPLIB, but I've not seen any commits to the CVS.

I am quite concerned that all these changes are going to be committed
in one hit with a comment like "merge changes from snapshot".

This will give users of PHPLIB no clues as to what changes have been
made and where to look for breakages in their apps.

So, two questions:

1. where is this development taking place?

2. are all the changes well documented and are the docs also being updated?

 ...Richard.

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@be...>]

Hi Richard,

On Wed, Nov 06, 2002 at 10:23:21AM +1100, Richard Archer wrote:
> I'm seeing all this traffic on the list about ongoing development to
> PHPLIB, but I've not seen any commits to the CVS.
> 

I'm sorry.  I thought this had already been covered.

There are two main reasons that the patches haven't been committed to cvs 
( at least by me).

1.  I had not previously done any cvs commits to the phplib project and 
didn't want to come in and start committing willy-nilly.

2.  It's my impression that the state of the current -stable cvs is 
basically frozen waiting for a release.

> I am quite concerned that all these changes are going to be committed
> in one hit with a comment like "merge changes from snapshot".
> 

They are pretty much available as individual patches on sf.net.

> This will give users of PHPLIB no clues as to what changes have been
> made and where to look for breakages in their apps.
> 
> So, two questions:
> 
> 1. where is this development taking place?
> 

sf.net patches.

> 2. are all the changes well documented and are the docs also being updated?
> 

The docs are not updated.  The current docs do not exist in the cvs.

You may be able to address two questions:

What are the release criteria we are looking for?

Do we need a -devel or -unstable cvs tree?

thanks,

Joe


>  ...Richard.
> 

Re: [Phplib-users] Current PHPLIB development questions

[Richard A. <rh...@ju...>]

At 18:06 -0600 5/11/02, Joe Stewart wrote:

>The docs are not updated.  The current docs do not exist in the cvs.

The user comments aren't there, but the base files are all there
(as sgml). It's a pita to update the sgml, but well worth keeping
the docs up to date.


>You may be able to address two questions:
>
>What are the release criteria we are looking for?

My preference would be for:

complete back-compatibility with existing applications
good documentation for the changes outlining possible breakages
not throwing warnings with all error/warning messages enabled
compatible with the new PHP defaults wrt globals etc (done?)
a switch in local.inc to choose phplib-session or session-4
examples of session-4 classes in local.inc and the html dir

The main thing I would stress is that this release should not change
the PHPLIB API in any non-compatible way. API changes may occur in the
8.0 release, but should not happen in an incremental release.

The only area where this may not be possible is in the session-4 stuff,
but this is OK as long as the old phplib-sessions are still intact and
back-compatible. Switching on session-4 for an existing app would be
something the developer would do in a test environment (one hopes!).


>Do we need a -devel or -unstable cvs tree?

There is a devel tree (it's the one that's not stable :). Unfortunately
this code is quite broken. It is really only useful as a resource for
ideas (like the session-4 stuff). I would be hesitant to over-write
this tree with a new suite of changes at this point.

I would like to see the rest of the good stuff merged from the "phplib"
tree into the stable tree, and the old "phplib" tree deleted (or
archived, whatever).

I think it would be quite a good idea to create a new branch for
development work. I would like to see it called "unstable" and to
include a file warning against inclusion of this tree for any
packaged release of PHPLIB. This would be an attempt at preventing
a repeat of the inclusion of the broken tree in several OS releases.

 ...R.

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@be...>]

On Wed, Nov 06, 2002 at 01:46:20PM +1100, Richard Archer wrote:
> At 18:06 -0600 5/11/02, Joe Stewart wrote:
> 
> >The docs are not updated.  The current docs do not exist in the cvs.
> 
> The user comments aren't there, but the base files are all there
> (as sgml). It's a pita to update the sgml, but well worth keeping
> the docs up to date.
> 

I don't believe this is accurate.  The linuxdoc sgml files that exist in 
cvs are not up to date with the docbook version.  The docbook xml and the 
associated files to output the finished documentation are not in cvs yet.

'make all' only creates the html version is the only problem I saw.

> 
> >You may be able to address two questions:
> >
> >What are the release criteria we are looking for?
> 
> My preference would be for:
> 
> complete back-compatibility with existing applications
> good documentation for the changes outlining possible breakages
> not throwing warnings with all error/warning messages enabled
> compatible with the new PHP defaults wrt globals etc (done?)
> a switch in local.inc to choose phplib-session or session-4
> examples of session-4 classes in local.inc and the html dir
> 

No switch in local.inc, but a separate prepend.php.  

> The main thing I would stress is that this release should not change
> the PHPLIB API in any non-compatible way. API changes may occur in the
> 8.0 release, but should not happen in an incremental release.
> 
> The only area where this may not be possible is in the session-4 stuff,
> but this is OK as long as the old phplib-sessions are still intact and
> back-compatible. Switching on session-4 for an existing app would be
> something the developer would do in a test environment (one hopes!).
> 

So, is this the current state of cvs?

> 
> >Do we need a -devel or -unstable cvs tree?
> 
> There is a devel tree (it's the one that's not stable :). Unfortunately
> this code is quite broken. It is really only useful as a resource for
> ideas (like the session-4 stuff). I would be hesitant to over-write
> this tree with a new suite of changes at this point.
> 
> I would like to see the rest of the good stuff merged from the "phplib"
> tree into the stable tree, and the old "phplib" tree deleted (or
> archived, whatever).
> 
> I think it would be quite a good idea to create a new branch for
> development work. I would like to see it called "unstable" and to
> include a file warning against inclusion of this tree for any
> packaged release of PHPLIB. This would be an attempt at preventing
> a repeat of the inclusion of the broken tree in several OS releases.
> 
>  ...R.

thanks,

Joe


> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Current PHPLIB development questions

[Chris J. <ch...@ch...>]

On Wed, Nov 06, 2002 at 01:46:20PM +1100, Richard Archer wrote:

> My preference would be for:
> 
> complete back-compatibility with existing applications
> good documentation for the changes outlining possible breakages
> not throwing warnings with all error/warning messages enabled
> compatible with the new PHP defaults wrt globals etc (done?)
> a switch in local.inc to choose phplib-session or session-4
> examples of session-4 classes in local.inc and the html dir
> 
> The main thing I would stress is that this release should not change
> the PHPLIB API in any non-compatible way. API changes may occur in the
> 8.0 release, but should not happen in an incremental release.
> 
> The only area where this may not be possible is in the session-4 stuff,
> but this is OK as long as the old phplib-sessions are still intact and
> back-compatible. Switching on session-4 for an existing app would be
> something the developer would do in a test environment (one hopes!).


> There is a devel tree (it's the one that's not stable :). Unfortunately
> this code is quite broken. It is really only useful as a resource for
> ideas (like the session-4 stuff). I would be hesitant to over-write
> this tree with a new suite of changes at this point.
> 
> I would like to see the rest of the good stuff merged from the "phplib"
> tree into the stable tree, and the old "phplib" tree deleted (or
> archived, whatever).
> 
> I think it would be quite a good idea to create a new branch for
> development work. I would like to see it called "unstable" and to
> include a file warning against inclusion of this tree for any
> packaged release of PHPLIB. This would be an attempt at preventing
> a repeat of the inclusion of the broken tree in several OS releases.
> 
>  ...R.

My thoughts exactly!  (Well, actually much more clearly stated than my
thoughts.)

I'm 100% in agreement with Richard.

It might make more sense to use the current "not stable" tree as a
source for ideas, as Richard suggested, rather than try to actually
merge everything or even most of what is in it into the stable version.
I think that would be a very large and risky undertaking.

-- 
    ..chris

Re: [Phplib-users] Current PHPLIB development questions

[Giancarlo <gia...@na...>]

I I'm 100% in agreement with Richard.
>
> It might make more sense to use the current "not stable" tree as a
> source for ideas, as Richard suggested, rather than try to actually
> merge everything or even most of what is in it into the stable version.
> I think that would be a very large and risky undertaking.

The dev snapshot has two new things: php4 session support & an auth redesign.

Php4 session support is quite stable and working by itself in the snapshot. 
It can be merged easily, it won't interfere with preexisting stuff. It really 
works. And is implemented much more simply than in the various previous 
'unsup' branches.
The new auth can be more tricky to distribute, and is based on some vital 
bugs found along  the way. These bugs have been backfixed into the cvs 
though. But as of now I do not necessarily see a problem in using it as a 
dropin replacement: it will work mostly everywhere, especially if the app 
sticked to the API, and didn't use to call directly functions as 
$auth->start() or $sess->freeze() or similar functions that were supposed not 
to be used but to be called by phplib. The cancel_login is the only thing not 
supported, it simply has no effect.

Gian

Re: [Phplib-users] Current PHPLIB development questions

[Giancarlo <gia...@na...>]

> though. But as of now I do not necessarily see a problem in using it as a
> dropin replacement: it will work mostly everywhere, especially if the app
> sticked to the API, and didn't use to call directly functions as
> $auth->start() or $sess->freeze() or similar functions that were supposed
> not to be used but to be called by phplib. The cancel_login is the only
> thing not supported, it simply has no effect.

In fact there used to be a few 'unsupported patches' around that used some 
workaround to get a 'login form' anywhere etc.
One of these used to set $auth->auth[uid]='form' so that it could call 
$auth->start anytime.
This is a typical example of something that would not work with the new auth, 
because the problem has been solved bothh by finding a bug and by eliminating 
 the 'unique entrance point' of the auth->auth[uid]=='form' state, that would 
block session everywhere and needed the cancel_login.

There are other 'usupported patches', that BTW never made their way into the 
official distrib, that would not work with the new auth. But all in all (ask 
those who looked at it), once you just read the new code and compare it with 
the old one, you understand that you don't want to go backwards anymore...

Gian

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@cm...>]

On Thu, Nov 07, 2002 at 10:11:26AM +0100, Giancarlo wrote:
> I I'm 100% in agreement with Richard.
> >
> > It might make more sense to use the current "not stable" tree as a
> > source for ideas, as Richard suggested, rather than try to actually
> > merge everything or even most of what is in it into the stable version.
> > I think that would be a very large and risky undertaking.
> 
> The dev snapshot has two new things: php4 session support & an auth redesign.
> 
> Php4 session support is quite stable and working by itself in the snapshot. 
> It can be merged easily, it won't interfere with preexisting stuff. It really 
> works. And is implemented much more simply than in the various previous 
> 'unsup' branches.

PHP4 session support is in the -stable cvs.  There is no difference in 
this portion of the code from cvs to the dev snapshot.

> The new auth can be more tricky to distribute, and is based on some vital 
> bugs found along  the way. These bugs have been backfixed into the cvs 
> though. 

No. no changes have been made to the auth in cvs.  So the bugs and missing 
features remain.

> But as of now I do not necessarily see a problem in using it as a 
> dropin replacement: it will work mostly everywhere, especially if the app 
> sticked to the API, and didn't use to call directly functions as 
> $auth->start() or $sess->freeze() or similar functions that were supposed not 
> to be used but to be called by phplib. The cancel_login is the only thing not 
> supported, it simply has no effect.
> 

Pretty much true, especially when not using default auth.  

The auth_validatelogin and do_register need to reject quickly if there are no
 POST variables.

Joe

> Gian
> 
> 

Re: [Phplib-users] Current PHPLIB development questions

[Giancarlo <gia...@na...>]

> PHP4 session support is in the -stable cvs.  There is no difference in
> this portion of the code from cvs to the dev snapshot.
>

Then it was the register_globals off compliance. I approached the two at the 
same time, so I considered it all 'php4 support' 

G

Re: [Phplib-users] Current PHPLIB development questions

[Joe S. <jo...@be...>]

On Thu, Nov 07, 2002 at 08:47:45PM +0100, Giancarlo wrote:
> 
> > PHP4 session support is in the -stable cvs.  There is no difference in
> > this portion of the code from cvs to the dev snapshot.
> >
> 
> Then it was the register_globals off compliance. I approached the two at the 
> same time, so I considered it all 'php4 support' 
> 

The register_globals off compliance for session4 are the changes made to 
the -stable cvs after moving from the unsup/phplib cvs.

There was a small compatibility issue with foreach as opposed to while.  
I'll see that these changes get made to session4.

I had forgotten about a change to auth that is in the current -stable cvs.  
Support for the __sleep() function was added.

Instead of changing auth.inc, an auth4.inc was created.

> G
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users