Re: Namespace issues

On Thu, May 16, 2002 at 11:58:47AM +0200, Bertrand Mansion wrote: > > 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. True, and the Fold class provides mechanism for that. Still there must be a default, and integration is much easier if there is a reserved and managed part of the URL namespace available to PEAR developers. So I suggest to amend the above language, resulting in the following rule for PEAR developers: For PEAR developers: Any PEAR class that needs URLs may use names below the /internal-pear/<classname>/ branch in a webservers URL namespace tree. Additionally, you must provide a method for the user of your class to change all generated URLs of your class to some different location. > > 2. GET/POST/COOKIE (GPC) namespace issues > > One can only agree. I would just go for something shorter than > internal_pear_<classname>. I was following the recommendation of the PEAR coding standard to use speaking names. Also, I was hoping to minimize the risk of accidental collision with some other names in use by choosing a longish name. Furthermore, I wanted identical prefixes in URL namespace, GPC namespace and global namespace. Finally, this is similar to what the Roxen web server uses, after which I modelled my example class. Do you have a suggestion for a shorter prefix, which can be used universally? > > 3. Session storage and session use > > There is no session class in PEAR which, personally, I miss a lot. I am not asking for a class here, but for a documented method of interoperation. That method may be implemented in a class, for convenience, but I'd like to avoid a global dependency. Thus, a method that may be implemented independently at the class developers discretion. > > 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. Again, see my reponse in 2. :-) Kristian