[phplib-dev] Re: Session4 (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:

>
> > 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).
did any tests? I am skeptical of using it until I make some perf. tests
on it.

> 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.
well, this depends on how you undestand a `Session' object.
Just like in C++, you can say ofstream f('foo.txt','w'); and have
the object ready to be used or ofsream f; and after that f.open().
[dummy example].

Now, when one sais `$foo = new Session();' shouldn't be concerned anymore
of any of it's internals. She must be able to call any functions and use it
to store and retrieve PHP variables. That's why I think `start()' is a part
of object initialisation.

> > 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.
maybe $sesson->setSessionDomain() would have sounded better. I meant to
have the opportunity to set the `domain' under which the session variables
will be available

> > 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 !)
? didn't got it. I was refering to the `$that' [sic] member of the session3
class which is out link to the underlying DB layer.

> 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" :( )
yap, this is the issue we want to clear out and fix first.

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

> > > * 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).
prune? :)

> 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?
you may have a different opinion, [in a well-known abv. :) ]
  
> 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
Agree. Now somebody has to write it :)

cheers,
-- teodor

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