Re: [phplib-dev] Re: [phplib] PHPlib session using PHP4 sessions implementation: the code From: Max Derkachev (kot <email protected>)
Date: 12/04/00

"R.B. Scholtus" wrote:

> Am i right that your main problem with the phplib-4 extension is that it
> does not provide phplib storage containers anymore?

The main problem with your extension (and the main feature of it indeed :) ) is
that it covers only standard php4 session storage modules. It does not support
'user' storage module.

> As of php4, how to store sessions data is a php4 issue and not a phplib issue
> anymore. For the mainstream (phplib) user php4 session storage is sufficient.

I doubt. It is only sufficient if you don't want any other storage besides
filesystem and shared memory. For me, the database storage is needed.

> If someone wants other ways of storing session data, then let them use the
> php4
> mechanism for this. It's not there for nothing! IMO the CT_* is obsolete for
> sessions. Maybe to complete a phplib using php4 native sessions we should
> provide some custom handlers. But they should be php4 handlers, not old
> stuff. Maybe/probably we can port the CT_* classes.

If you bother to look at CT_* classes you'll find that they aren't obsolete at
all and can work very well as custom handlers for the user session storage
module. They have nothing to do with any of the session implementation - old
phplib's or of php4. They don't even know how they are exploited by an external
class - they are just the any storage abstraction. Custom handlers are nothing
more then functions to store the data somewhere and retreive the data from
somewhere. It can be used by session module, or anything other you could
imagine. If you need a new one - write them. But CT_* stuff is tested and
stable, so why don't you hack them if they are not sufficient instead of
inventing a bicycle? CT_* class and ac_* methods are nothing more then function
names for the session module, so do we need to abandon phplib's naming
conventions for the sake of "making them PHP4-compliant" ? :)

> I didnt say the phplib-4 extension is complete. I did say that usually it
> should be installable within 30 seconden without any compatibility problems.

Well, phplib-4 is only wrappers to standard php4 session (with standard session
modules). No more no less. I do think that such a module to be a part of the
"PHPLib for PHP4 (C) " :)). It should handle sessions, when standard storage is
sufficient. But I think the goal of the phplib is to make some complicated
tasks simple (always been), and we should provide a good interface for custom
storage of the session data.

> If the storage is your main concern, then i would like to known why you
> didn't contact me or anyone else on cvs or dev list to offer your help on
> the issue.

> We have 3 'ports' now. It shows great stupidity (and lack of
> management) to re-reinvent the wheel and it makes ASP/JSP programmers laugh.
> Looks like the stupidity points to me first. 15 minutes after i published my
> solution, it appeared there was a solution already (Theodor, i feel so
> stupid, i didnt know....... :-))
>

Well, I've done the work :). I've got a cvs account at phplib's repository, and
we should deside how to merge our efforts and not to waste our time in this
flame. I'm ready to commit my patches, so let's deside on a structure of the
new session module and integrate all three into one.
I guess some changes ought to be made in a structure of the module to prevent
conflicts - the user should specify if he intend to use standard session
storage (Your and Theo's module) or user module (mine). Maybe it should be
cpecified in prepend.php, so the necessary module would be included. Maybe we
should make a basic Session class, and then make extensions to it, covering
standard php4 storage modules and the user module, which uses custom
containers.
Waiting for your comments. 

--
Best regards,
Max A. Derkachev mailto:kot <email protected>
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-5353
http://www.Books.Ru -- All Books of Russia

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-dev-unsubscribe <email protected>
For additional commands, e-mail: phplib-dev-help <email protected>