Re: PEAR 1.3

On 20 Aug 2003 at 12:41, Greg Beaver wrote: > 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. Agreed. So let's keep it simple. You're right in what you said. Stefan