Re: Namespace issues

le 16/05/02 10:56, Kristian Koehntopp à kris@koehntopp.de a écrit : Hi Kristian, You point out some interesting topics. > 1. Image namespace issues/URL namespace issues ... > "For the admin/application developer: > PEAR reserves the right to use the /internal-pear branch in > your webservers URL namespace tree. Your application must > not use URLs starting with /internal-pear for its own > purposes. > > For PEAR developers: > Any PEAR class that needs URLs may use names below the > /internal-pear/<classname>/ branch in a webservers URL > namespace tree." I would prefer to let the user decide where he wants to put its images on his server. So I would favour a setImageDirectory() method. > 2. GET/POST/COOKIE (GPC) namespace issues ... > That is, as a PEAR global rule, > > "For the admin/application developer: > PEAR reserves the right to use GPC variable names > starting with internal_pear on any page. Your application > must not use GPC variables starting with internal_pear. > > For PEAR developers: > Any PEAR class that needs GPC parameters may use names > starting with internal_pear_<classname> in the GPC > namespace. One can only agree. I would just go for something shorter than internal_pear_<classname>. > 3. Session storage and session use ... > On a PEAR global scale: > > When a PEAR class needs sessions, what kind of code is > required to check that sessions are not already started, and > if not, to start the session? Should PEAR classes start > sessions themselves or should the session management > configuration be left to the PEAR class user > (administrator/developer) and only be noted as a requirement? > > Should PEAR classes store their objects as part of the session > or should they store a classless hash as part of the session and > use that hash instead of their object-internal data, in order > to keep the size of the session small and in order to save code > includes which must be part of each and every page? There is no session class in PEAR which, personally, I miss a lot. For instance, it would be much more efficient to have an Auth class which knows how to handle sessions just like it was in PHPLib. Many common client-server tasks are linked to sessions so I reckon we need one. I think sessions should be managed globally in PEAR just like the error handling stuff. It might be good to have each object with a need for sessions to implement an encode and a decode method. PEAR could then let know the object if a session was already started. This is going to take some time to implement I guess. > 4. Namespace in Sessions and in GLOBALS > > How do we handle namespace issues in sessions? When a PEAR > class wants to use variables that have to become of the session, > or of the global namespace, what names do we reserve here? > > Again, I propose internal_pear_<classname> for use by PEAR. See point 2. Bertrand Mansion Mamasam