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

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 world of difference. 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 PEAR_LOCAL_CONF and PEAR_GLOBAL_CONF environment variables to find these files. Obviously these locations would be different on Windows (are there any windows installations in the world used as servers with virtual hosting that would need this?), and most likely a global installation will be fine, or completely separate installations for each user, since permissions are non-existent. However, the same principle could in theory be applied. I don't have a Mac with OS X, so perhaps our resident experts could comment. As I understand, it should be the same principle as other unices. When installing PEAR locally, it could ask if you want to modify your .bash_profile to add the export 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 have to package phpDocumentor for a new release :) 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. 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"? Greg