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

Hi Brian.

"R.B. Scholtus" wrote:

> 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!).

No, you can not. Only standard builtin session storage - files and shared
memory. The php4 feature is to provide an interface for custom user session
save handler.

> 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.

No, you're missing PHP4 session storage conception. You can not start using
database or other non-standard storage just by editing the php.ini. The only
thing php.ini can do for you is to set session.save_handler to 'user'. The only
way to do database, dbm, ldap or other storage is write your own custom
functions to handle write, read, delete session data, to open and close the
session and garbage collection function. Then you should pass their names to
session_set_save_handler() - this is the only way to make PHP4 session engine
to store data in a non-standard storage.

> 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.

Once again, you can not define your session data storage only once in php.ini.
What for CT_* stuff, it works perfectly as custom storage functions for
session_set_save_handler(), so why to write another code, if something is made
before, tested and stable?

> 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.

You can start using RAM as session storage just now with you class - just set
session.save_handler = mm in your php.ini (I'm not sure, may be you'll need an
mm library module compiled in php). With ramdisk is also a good idea - you
won't loose all session data if apache or php cgi fall in core (if you use mm
storage, the memory is reserved by php -if it fail, all memory will be freed).

> The, for example, serialize() function is this there while not being used by
> the phplib-4 extension. Just in case someone uses it! (why???)

User class is using it.

> 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 :-)))

Good idea.

> 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 didn't say that your class is bad. It simply does not handle custom storage,
just standard ones.

Good luck. 

--
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>