[phplib-dev] Session4 (Re: [phplib] How stable is PHPLib-Dev) From: Jeroen Laarhoven (jeroen <email protected>)
Date: 09/27/00

> My Q was specifically because one *can* change them during a session.
> string session_id ([string id])
> string session_name ([string name])

Oke, sounds good.

> My argument is that 99% of programers won't use output buffering,
> so they must have the `session_start' code somewhere on the beginning
> of the page/script. There one would do $SES = new Session(); so it
> makes sense to start it.

I use output buffering ... (wrapping pages).
And I believe that constructors should only construct (initialiaze), so I am
very careful with putting to much functionality in constructors. Quite often
you find out you have to remove it in the end.

> I was thinking, for example, at something like
> $session->setCookieDomain('/members/'); to send cookie to that subdomain
> only (say it was previously set to `/'). etc.

Hmm, don't know, I am not sure I think that cookies are a part of sessions.
But the PHP4 people seem to see it this way. Or I am still missing bits?
Are these setting for ALL cookies, also when you use SetCookie()?
If so, I do not think they're a part of session.

> Yeah, maybe the user configurable session handlers should replace the
> old `session->that' member functionality, giving the opportunity to
> specify it in the same way it was until now (deriving a new class)

But then please $this->storage or so, who ever thought that this->that is
readable code ... (but I like the humor in it !)
But lets now first get this baby up and running, letting people configurate
by hand, it seems that many are waiting for this.
(But I am sure that when it is up and running, people start asking: "nice,
but how do I reuse my old MySQL, Oracle, ... data" :( )

> Note that I only stole some time and sketch a session4.inc idea. I haven't
> tested the other classes that lean on session?.inc to see if it broke
> something. We should go and see that first, then split it to be cleaner.

I'll try it on our ported project using sess, auth (modified quite a lot)
and user. I hope to have some time this and next week.

> you mean url() or add_query().
> I tested url() and it replaces an existing `session_name()`.
> I rewrote it somehow obscured,(Sascha pointed that already) but I would
rather
> (re)move it elsewere too.

Does url() also work if there is more stuff around the session_id? I do not
remember.

> > * string serialize ()
> > * bool deserialize ()
> another name for the same thing, same reason for which
session_(en|de)code()
> though I dunno how many of PHPLIB.Session users will use them.

In the old days they did all the (de)serialization, not ONLY the
(de|en)coding, so I wouldn't use them for that now. The session coding
functions are usefull only for writing handlers (lower level).

One problem I however still have is that I made a class for showing 'live'
data of sessions (eg. who is/has been online recently and what are/were they
doing :] ) using some deep session stuff, all gone now.
I think we (I do - so will try to build it) also need some stuff (seperate
class) to handle 'stored' sessions.

> YMMV, but from what I undestand it only specify a session container, which
> is no longer necessary right now.

YMMV?

> Maybe we should add here a `session_set_save_handler' functionality?
> The one major problem that i see is with the legacy data. How should
> we transfer existing data (most of them in MySQL tables) to the new
> session storage?
>
> And here I think many of the users would like to have `save_handlers'
> to use the same databases, same tables if possible.

I found out that I made a design error using $user for storing data. It
works great, but now we're talking about integrating (parts of) our site in
other sites I noticed that this storage should be layered.
Session storage is oke, but user data storage should be seperate and be more
portable (eg. by using XML or any other interface). And this storage
interaction should not be done on every page_open/close(), but only when it
makes sence.

In my (humble) opinion, the session data (table) should be deletable at all
time (sorry for online users).
And as said before user data storage should be done another way. So I am not
sure if in this case there is a use for User left for me ...

But User can be handy for many! And they might want to keep their data :)

Greetings
Jeroen.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Jeroen Laarhoven, Zwolle, Netherlands
email: jeroen <email protected>
www: http://jeroen.polder.net
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

----- Original Message -----
From: "Teodor Cimpoesu" <teo <email protected>>
To: "PHPLIB-DEV" <phplib-dev <email protected>>
Sent: Wednesday, September 27, 2000 12:37 PM
Subject: Re: [phplib-dev] Re: [phplib] Re: [phplib-dev] Re: [phplib] How
stable is PHPLib-Dev

> Hi Jeroen!
> On Wed, 27 Sep 2000, Jeroen Laarhoven wrote:
>
> > Comments (asked for!) on teo's work and DEVELS-NOTE:
> >
> > o What do you think, should we have class members for session name
> > and ID, or to fetch them using session_*() funcs?
> >
> > Since they are not changing during a session I guess vars should be oke.
>
> My Q was specifically because one *can* change them during a session.
> string session_id ([string id])
> string session_name ([string name])
>
> > o Should we add a constructor to call session->start() and fill this
> > properties?
> >
> > I am not sure about the constructor 'doing things', it might be called
at
> > the wrong moment.
>
> My argument is that 99% of programers won't use output buffering,
> so they must have the `session_start' code somewhere on the beginning
> of the page/script. There one would do $SES = new Session(); so it
> makes sense to start it.
>
> >
> > I would make start() filling the properties, since at that moment
they're
> > known first.
> right.
>
> >
> > o What about the other session_* functions. Should we extend this
> > API to include such functionalties like cookie params and save
handlers
> > or should we think another session class?
> >
> > No I wouldn't add these, since these are a lower level functions for
> > handling and configuration of the session storage yourself.
> I was thinking, for example, at something like
> $session->setCookieDomain('/members/'); to send cookie to that subdomain
> only (say it was previously set to `/'). etc.
>
> Yeah, maybe the user configurable session handlers should replace the
> old `session->that' member functionality, giving the opportunity to
> specify it in the same way it was until now (deriving a new class)
>
> > This might also be a good time to 'clean up' the sessions class.
> +1
>
> > I would make a clean new base class for new users/projects without all
the
> > 'romantic functions'. Then make a Session_BackComp or someting class
> > extending
> > this class and adding ALL these functions for compatibility with old
code.
> > New projects: use the clean class, old code: use the compatible class.
> Note that I only stole some time and sketch a session4.inc idea. I haven't
> tested the other classes that lean on session?.inc to see if it broke
> something. We should go and see that first, then split it to be cleaner.
>
> > API's:
> >
> > Session:
> > * bool start()
> > * string name ()
> > * string id ($sid = '')
> > * bool register ($var_names)
> > * bool is_registered ($var_name)
> > * bool unregister ($var_names)
> > * bool delete ()
> > * string get_hidden_session ()
> >
> > Session_BackComp:
> > * string get_id ($sid = '')
> > * bool put_id ()
> > * void purl ($url)
> > * string pself_url ($url)
> > * void hidden_session ()
> > * string get_hidden_id ()
> > * void hidden_id ()
> >
> > Not sure:
> > # I am not sure query param handling should be a part of Session.
> > # and this code is not perfect ... e.g. it does not replace a var if it
is
> > # already in the query.
> you mean url() or add_query().
> I tested url() and it replaces an existing `session_name()`.
> I rewrote it somehow obscured,(Sascha pointed that already) but I would
rather
> (re)move it elsewere too.
>
> as for add_query(), I agree it doesn't belong to Session.
> In the Servlet API, there is a special class (HttpUtils) that has such
function,
> for example. And logically, it has nothing to do with the Session.
>
> > # (I made a query handling class and override the session functions
using
> > this,
> > # but this has at least one known problem still in it ...)
> > # And there is --enable-trans-sid (I love it !!!) so I would say
BackComp.
> > * string url ($url)
> > * string self_url ($url)
> > * string add_query ($qs = '',$qarray)
> > * void padd_query ($qarray)
>
> > # Do not see the use of these:
> > * string serialize ()
> > * bool deserialize ()
> another name for the same thing, same reason for which
session_(en|de)code()
> though I dunno how many of PHPLIB.Session users will use them.
>
> > # And do not think these now have to be part of Session, maybe
BackComp:
> > * void reimport_get_vars ()
> > * void reimport_post_vars ()
> > * void reimport_cookie_vars ()
> > * void reimport_any_vars ($arrayname)
> I am for rm-ing.
> a simple array_merge ($GLOBAL, $HTTP_*_VARS) should do this.
>
> > Has anyone looked to user.inc yet?
> yap.
> > Have these changes any inpact on that?
> YMMV, but from what I undestand it only specify a session container, which
> is no longer necessary right now.
>
> Maybe we should add here a `session_set_save_handler' functionality?
> The one major problem that i see is with the legacy data. How should
> we transfer existing data (most of them in MySQL tables) to the new
> session storage?
>
> And here I think many of the users would like to have `save_handlers'
> to use the same databases, same tables if possible.
>
> -- teodor
>
> ---------------------------------------------------------------------
> 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>