> Perhaps, and here is something to think about, pseudo-random is
> not what the developer wants as a session ID.
Well, provided that there is a device which captures white
noise, you can also get real random session ids with the
current code.
> The storage handlers need not calculate the session id. In
> fact, most will not. However, if they have a real purpose in
> needing to generate session ids, that capability is provided in
What purpose? So far, I have not seen any reason why they
would want to do generate their own session ids. If there
are any, please share your wisdom.
> > Currently, session ids have a defined format which our users
> > rely on. If storage handlers control the format, they might
> > choose to change it for some odd reason. Thus our users'
> > deployed applications might break out of the blue.
>
> That is the risk with any session handler, regardless of ID
> format. That is the risk of providing an extension API. If the
> session handler does not work correctly, it will break
> applications. Saying "no you can't do that because we'll look
> bad" is a pretty lame excuse for reducing flexibility that
> extension developers are asking for.
That reply appears to be unrelated to the quoted paragraph.
> It isn't just about session collisions. It is about having the
> extension create he session and ID that goes with it.
Well, I'd welcome a patch which enables storage handlers to
validate/invalidate newly created session ids.
Based on the reasons you have given so far, I don't see any
advantage for users in letting storage handlers generate
session ids.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
