Re: PEAR 1.3

From: Date: Wed, 20 Aug 2003 16:41:50 +0000
Subject: Re: PEAR 1.3
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-20167@lists.php.net to get a copy of this message
Stefan Neufeind wrote:
Why not generally allow that multiple directories can be configured and pear will work on all of those? E.g. if you insert multiple web- directories these might all be used.
The current structure of Config is designed for single values. In addition, every time a value is added to the config, it will require installation of existing packages to those directories, unless there is a new command just for publicweb. Deleting directories would most certainly require automatic uninstallation - it begins to get REALLY complicated. The registry is also set up so that there is 1->1 relationship between original file and installed location, and would require a hack to change this just for publicweb.
Another thing that now comes to my mind: What if you want to install a package that provides also web-frontends (like a guestbook or something) but you don't want to put it in the webroot. Or not into all webroots but only for one person/virtual host.
This would best be handled by a separate PEAR install - I don't think it is feasible to provide this level of customization for global installs (this package is installed to these publicweb dirs, this package is installed in this subset), otherwise it will require set theory to keep track of them all :). Also, a web frontend should by design never be tied to data directly, i.e. for a guestbook, the code controls the contents of the guestbook. This does raise a really important point - publicweb should ONLY be used for static files like straight .html, .css, .js, and images. all PHP code can easily be included - even for situations like the docbuilder web interface for phpDocumentor, which doesn't follow this rule entirely (includes/utilities.php should be role="php"). I will change this for the next release, so that all functional code is in role="php", and display only includes the basic display code. I think Klaus may be on to something - his solution allows the patch to remain in its simplest form - a 6/7 line addition, with no need to do any acrobatics. Webservers are well-configured to set up virtual directories for hosting, and users can do what they wish. The added complexity to the core of PEAR will not be a pretty sight if publicweb is set up to allow multiple installation directories. Greg

« previous php.pear.dev (#20167) next »