>> Should php create the session id, or should the session handler? > > PHP should. Here is something to think about. > > It is hard to generate hard to guess session ids. PHP has > various internal entropy sources and can read from system > provided entropy sources as well. That gives PHP users an > adequate level of pseudo-random session ids. Perhaps, and here is something to think about, pseudo-random is not what the developer wants as a session ID. > > If storage handlers would generate their own session ids, > they would have to reimplement all of the above. Because > that it is an uneasy task, many (most) storage handlers will > get it wrong. And which project is the most likely to be > blamed for that? PHP, because it would give too much control > to storage handlers. 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 the patch. The srm project and msession project will benefit from this capability. > > 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. > > Up to now, noone has claimed that the session module ever > produced collisions among session ids. If the opposite can > be shown, I'd favor fixing session id generation in one > place, instead of the X storage handlers in the wild. It isn't just about session collisions. It is about having the extension create he session and ID that goes with it. The argument as I see it is this: What harm does it do to apply the patch? Are there any functional reasons why this won't work? If you want to insult the extension developers by saying we will do it wrong, I take offense to that. Who are you to critisize the people that try to contribute to PHP? That seems very rude.
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
