Why is it you do not wish the session save handlers to be able to generare their own session IDs? The patch does not break any save handlers, but adds a lot more flexibility to the session system. A pseudo-random number may not be what is desired. I may want the session id to be the user's name. I may want it to be their IP address. Who knows? That is the point of flexibility, choice. In a web site that does not use only PHP, maybe a save handler may need to query anoher system to get the session ID from that. There are lots of reason to commit the patch. And only your fear that session hander writers will (in your words) "get it wrong." (Which, by the way, is quite insulting, you should try to respect the people who contribute.) Your position is valid only if you assume eeryone wants the session ID to have the same properties that you do. If that is the case, why have extensions at all, PHP should just be what it is, because no one should want anything different. Hell, why should it be open source, someone can change it and "get it wrong!" Make it closed source, that will fix everything. If the patch does not break anything, and to my knowledge it doesn't, why not add it? What is the harm? The question of "should" has already been answered by a few developers. It should now be a technical discussion of the impact on the code as a whole, and there should be none beyond adding functionality. >> 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
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
