[prev in list] [next in list] [prev in thread] [next in thread] 

List:       phplib-dev
Subject:    [phplib-dev] custom session save handlers
From:       "R.B. Scholtus" <regiment () dds ! nl>
Date:       2000-12-05 17:06:13
[Download RAW message or body]

Hello all,

I have been considering the implementation of the custom session save
handlers. Under php403pl1, i cant get it to work in a nice class-form. Only
with simple functions. It looks like we need php404 for these classes to
work.

My consideration is that it would be okay to support custom save handlers
for php404+ only. If someone really wants to install a custom handler for
whatever reason, im sure they really want to have the latest php4 also.
Otherwise i really dont understand their priorities.

Another consideration my collegue and i discussed is that a sql save handler
should be lots-and-lots slower than default session storage. Databases
provide extra services which are not necessary for simply saving some data.
So the questions is: why would someone use a custom handler? 'Files' work
fine and 'mm' should be lightning fast. Another reason to say that support
for custom handlers for php404+ only is okay.

So what way to go? A structured approach for all php4 versions now (works
already), or wait for php404 and implement a nice class structure?


Brian

----- Original Message -----
From: Max Derkachev <kot@books.ru>
To: R.B. Scholtus <regiment@dds.nl>
Cc: <phplib-dev@lists.netuse.de>
Sent: Monday, December 04, 2000 10:01 AM
Subject: Re: [phplib-dev] Re: [phplib] PHPlib session using PHP4 sessions
implementation: the code


> "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@books.ru
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-5353
> http://www.Books.Ru -- All Books of Russia
>


---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-dev-unsubscribe@lists.netuse.de
For additional commands, e-mail: phplib-dev-help@lists.netuse.de

[prev in list] [next in list] [prev in thread] [next in thread]