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

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

> Hi Max,
>
> I think it is great someone else is also thinking about solutions, thanx!
>
> About the storage of the session data:
> I must admit that my phrase in the phplib-4 extension documentation is a
> little stupid:
> > "This goal of this extension of phplib is to let phplib use PHP4 native
> > sessions instead of using a database for storing sessions data."
> I should have written '... instead of using phplib's default storage, a
> database.' I hope that it is clear to you and everyone else that with the
> phplib-4 extension, you can use files, mysql or any other storage (duh, of
> course, it's a php4 feature!). So i DO differ between the session engine
and
> the storage. But as of php4, the session data storage is a php4 config
issue
> and not a phplib config issue anymore. That's why i didnt want to use any
> CT_* stuff anymore for the sessions (for the User i do, sure). I guess it
> also makes things easier if you define your session data storage only
once,
> in php.ini. You dont have to configure CT_* containers every time. With
the
> phplib-4 extension, you can reconfigure php4's session data storage
handling
> if you don't like php4's developers' choice to use /tmp files.
>
> A little bit off-topic, but still important:
> For high traffic sites, probably the fastest way of doing sessions is to
> store the session data in memory. This should be as easy as storing the
> files on a ramdisk (is that called virtual disk?) instead of in /tmp and
> adding some RAM maybe. But this is just a wild guess, im not a expert on
> this kind of administration!!! Anyone here who is? Please help us, i know
> some people who want to know!!!
>
> About the code:
> I didnt empty those functions in session.inc for nothing, but because i
want
> them to be there for 100% compatibility. They are totally useless because
> for the phplib-4 extension they relate to old stuff. But i hate it when a
> customer reports errors on my sites because
'some-kind-of-internal-function
> seems to be missing' because someone's old code is (inappropriately!)
> referring to them. This should never happen, but i just want 200%
> compatibility :-). Probably these internal functions can/will be removed
> when a new version of phplib comes out.
> All phplib session functions that are normally used (as documented on
> phplib.netuse.de) remain exactly the same. Only the inside of the black
box
> is different........
> The, for example, serialize() function is this there while not being used
by
> the phplib-4 extension. Just in case someone uses it! (why???)
> The phplib.netuse.de documentation is still valid when someone is using
the
> phplib-4 extension.
> My first simple attempts failed to port class User, but it works perfectly
> now!
>
> This comment of mine.......*sigh*
> > > the only thing i want to make it [phplib-4 extension] 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 :)
> Again, i phrased so unclear...geeez brian.
> What i meant is that the session class (or prepend.php3, even better)
should
> figure out if we are using php3 or php4, so whether it can and will use
php4
> native sessions or not. But this decision is just a config thing, it
doesn't
> affect our actual code, so the hell with it :-)))
>
> I think the phplib-4 extension a great one. It is 100% compatible and it
is
> very close to php4 sessions and should thus be a very fast way. If anyone
> misses a feature, please let me know!
>
> I think this is a phplib-dev issue as well, ill publish the discussion
there
> too.
>
> Bye bye now
>
> Brian
>
>
> ----- 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>