Re: semi-RFC: new file role needed: docroot

On Sat, 26 Jul 2003 13:47:09 -0400 Greg Beaver <greg@chiaraquartet.net> wrote: > Hi Martin and company, > > Martin Jansen wrote: > >>>How will you handle machines with multiple virtual hosts, where > >more>>than one document root exists? > > This problem is not unique to the new file role, and is a great one to > > resolve. I'd like, for instance, to be able to install pear on the > virtual host for chiaraquartet.net, but I have no root access, and > they won't install PEAR globally. I know I could just upload an > installed version from home, but this is a major pain for upgrading, > and none of the replacements are correct for those files that specify > it. it seems to me that it is actually quite simple to tell pear > where to find its conf file, and to use settings from that file to > determine where to install things. This change to the pear installer > (differentiating between the php_dir and pear_conf_dir) will make a <snip> > world of difference. here you may use the webinstaller and frontend. > We can resolve conflicts between installs of pear through the > incredibly simple method of include_path: put local include_path > before global. This would mean that either the local host could alias > pear webroot (as suggested by Jan - obviously any kind of auto-symlink > is bad security), or the local user could install a local pear that > installs the webroot. It may even be possible to implement a > communication between local and root installs, so that the local pear > could call the global pear with "pear list-all" and then use a special > install-web command that would only install those files that are > role="web." > > From a programming standpoint, I think the practical requirement will > > be a .pear directory, containing the pear.conf file(s), or /etc/pear > for global. the global pear command should look in the <snip> > PEAR_LOCAL_CONF=~/.pear/pear.conf (and ask for the name of the > .bash_profile, in case auto-detection code fails), and that's about > all I can think of right now. > > In any case, I think the above code will make file > role="webroot/docroot/web/http/whatever is decided" a possibility. I > can't wait, I hate modifying PEAR_Common::analyzeSource() every time I those variables already exists. PEAR use them in preference to default values if they are set. You can even set them in your httpd.conf by virtual host. Win32 uses them as well for the pear command itself, you can set them as you need. A sample registry file (to add to the win32 registry, it sets the correct ENV vars) is availalbe through go-pear, which is the way to install pear on win32. A good thing is to use them on all platforms. > I *really* like Alex Merz's idea and implementation of file roles, I > would suggest using xml namespaces to define which class should be > used to parse a file role at the top of the package, so that download > information can be specified. I don't have a clear sense of the best > way to do this off of the top of my head, so other ideas are > appreciated. In addition, the FileRoleHandler class would need to > implement PEAR_Common's getFileRoles(), but that is minor and simple. Same here. I discussed such things with Sebastion. Many applications need such things. But as you, I do not have a good idea right now :). > I personally prefer that directory conventions should follow the > role="php" and not role="data" conventions, so HTML_TreeMenu's things > are in HTML/TreeMenu and not HTML_TreeMenu/. > > Does anyone prefer role="docroot" or role="web", role="http"? not http, the other sound good. pierre