Re: [phplib-dev] Re: [phplib] PHPlib session using PHP4 sessions implementation: the code From: R.B. Scholtus (regiment <email protected>)
Date: 12/01/00

Hi Max (, Theodor and other developers),

Am i right that your main problem with the phplib-4 extension is that it
does not provide phplib storage containers anymore? 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. 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.

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.
And i dont know what it really lacks either. I'm waiting weeks already for
bug reports, where are they gentlemen??? :-)

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

Theodor stated in a post that the phplib session API should be rewritten
more cleanly:
> I would reform and say it straight that PHPLib session API is to be
rewritten
> to use PHP native session API (which futher suports this and that) and to
> enhace the current one with backward portability in mind.
Maybe it should. Maybe the phplib Session class is obsolete anyway. But
unless really necessary, i hope that we can go with an existing
'fix-it-decently' solution and concentrate on more innovative ideas. Im
looking 6 months already for something that integrates Template, DB_Sql,
Table and Form well (to create admin pages faster yes).

> > 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 wouldn't go with such "click-me-wizard" thing. The webmaster should know
>what's install and what wants to run, IMO.
Hihihihi i agree.

My .2 euro :-)

grtz,

Brian

----- Original Message -----
From: Max Derkachev <kot <email protected>>
To: R.B. Scholtus <regiment <email protected>>
Cc: <phplib <email protected>>; <phplib-dev <email protected>>
Sent: Friday, December 01, 2000 9:37 AM
Subject: [phplib-dev] Re: [phplib] PHPlib session using PHP4 sessions
implementation: the code

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

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