[phplib-dev] Fw discussion 3: [phplib] PHPlib session using PHP4 sessions implementation: the code From: R.B. Scholtus (regiment <email protected>)
Date: 11/30/00

----- Original Message -----
From: Max Derkachev <kot <email protected>>
To: R.B. Scholtus <regiment <email protected>>
Cc: <phplib <email protected>>
Sent: Thursday, November 30, 2000 6:39 PM
Subject: Re: [phplib] PHPlib session using PHP4 sessions implementation: the
code

> Hi Brian,
>
> "R.B. Scholtus" wrote:
>
> > Hoi Max,
> >
> > Wow, you have another lets say port of phplib. hihihi we have 3 of them
now
> > :-)
> > The first one is written about 2 months ago. The second was written by
me, 6
> > weeks ago. and now you have the third one.
>
> Of course I did notice the previous efforts, and do not intend to reinvent
the
> wheel. But the functionality that existing ports in cvs tree provide is
not
> sufficient for me, thats why i wrote my own.
>
> >From README4 from your phplib-4 distribution:
> "This goal of this extension of phplib is to let phplib use PHP4 native
> sessions instead of using a database for storing sessions data."
>
> The goal of my extension is to let phplib use PHP4 native sessions, while
using
> a database, or any other container for the session data. And my extension
does
> so. The right thing in PHPLib is to differ between the session engine
itself
> and the storage of the session data.
> Why do you think PHPLib developers made the lib to store data in anything
but
> the filesystem? It's so simple! But all the time PHPLib has existed, the
> preferred way was to use a database.
> I do think that the default way - using plain files in /tmp - is not
productive
> enough, especially on large-scale sites. To share sessions between several
> physical servers you'll find it inconvenient to use nfs or something like
that.
> If you use custom containers instead, you'll find it possible to store the
data
> everywhere you want - in a relational db, in a dbm, ldap or something
else -
> just make a standard CT_Something class, if it does not exist.
>
>
> > Your port is still using a lot of old session stuff right? did you
manage to
> > make it compatible?
>
> "Old session stuff" means CT_* container methods? Yes. The goal was to use
that
> containers, because they are good enough to handle custom PHP4 session
storage
> implementation.
> As for compatibility, I switched the old and my session classes to and
from
> several times on an app that was written using PHPlib 7.2. Works fine. I
did
> not find incompatibilities. With the new class, however, it works much
faster.
>
> > Well, whatever, my extension is 100% compatible and is completely
> > transparent. you can make a existing php3 + phplib site use php4
sessions
> > within seconds. the API is the same.
>
> Yes. The api in your class is a mix of existing PHPLib Session methods and
> several empty function definitions (commented code means empty) :). The
methods
> in my class, however, not only have the same names, but they are actually
do
> the same work, but the new way.
>
> > i have some good documentation on how
> > to 'install' and use it.
>
> For my class there is also a good documentation - the PHPLib's
documentation
> :). I wrote about some incompatibilities that can occur (especially with
User
> class). I have not much time now to fix user.inc to be compatible with the
new
> class, but one can use old session class, say, rename it to Session7 and
> inherit User from the Session7 class, and everything will work fine. Maybe
I'll
> patch the user.inc in the near future.
>
> > the only thing i want to make it do is to decide for itself wheter it
> > should use php4 native or phplib sessions. this would make it even
easier to
> > install. i dont know when a new version of phplib will come out, im
> > wondering.
>
> You'll find it much better to use native php4 sessions with custom
containers,
> that current PHPLib provides :)
>
> --
> 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>