Re: [phplib-dev] Re: [phplib] Re: [phplib-dev] Re: [phplib] How stable is PHPLib-Dev From: Teodor Cimpoesu (teo <email protected>)
Date: 09/27/00

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>