Re: Namespace issues
| From: | Martin Jansen | Date: | Thu, 16 May 2002 19:01:25 +0000 |
| Subject: | Re: Namespace issues | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-6165@lists.php.net to get a copy of this message | ||
On Thu, 16 May 2002 10:56:45 +0200, Kristian Koehntopp 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 don't how this can be realized in a multi-hosting environment:
The PEAR installer needs to copy the files to some place
during installation. How will the different virtual hosts be
able to access this files later?
The administrators would need to create symbolic links
in the vhost configuration like
<VirtualHost 192.168.0.10>
ServerName foo.bar.com
DocumentRoot "/var/www/foo.bar.com/htdocs"
Alias /internal-pear "/usr/local/lib/php/data"
</VirtualHost>
which a lot of mass hosting providers will surely not do. Do you
have an idea on how to solve this?
>2. GET/POST/COOKIE (GPC) namespace issues
>
> "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.
This sounds like a reasonable point, but I'm not sure if
the name is well chosen. I would very much prefer
PEAR_<package>_<somevar> (or the lowercased equivalent).
>3. Session storage and session use
>
> 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?
Eventhough I today pointed out that a session manager would
be IMO nice for PEAR, I'm right now not sure if this isn't
pure overhead. Maybe it would be the best thing to simply use
session_register() & friends in PEAR.
> 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?
I don't have a very strong opinion on this and I would like to
hear some additional comments on this.
>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?
As you already saw for yourself, this question is answered
by the coding standards.
- Martin
--
Martin Jansen, <mail@martin-jansen.de>
http://www.martin-jansen.de/