Re: Re: Channel questions

Sven Drieling wrote:

Am Donnerstag, 21. April 2005 01:14 schrieb Greg Beaver: Hello Greg,

If so, is there a mechanism for resolving naming conflicts?

yes, first come, first serve (existing files are not overwritten).

A concept that avoids/reduces name conflicts would improve this. What happens if someone else starts using the Chiara_ prefix and a different PEAR_Server with a different API is installed before Chiara_PEAR_Server? The short answer is: um, have you seen any? I haven't. :)

When one looks out at the real state of things in the PHP world, I think you'll find that there are very few classes that solve the same problem that have the same name (like "File"), but most classes have unique names. I would say in answer to your question: that just won't happen in the real world, but if it does, then either the two folks need to butt heads until a new name is chosen, or users will not be able to install both packages at the same time without using a different install dir for each channel.

Then there will be PHP systems with the same package/classnames but different APIs. On some systems a script will run and on another it will not. And it's then hard to know what's the reason because the bug report claims that the required class is installed (same name and version "pear list" but different function, API). Not so.

pear list shows only installed packages from the default channel - you have to specify a specific channel with the -c option, or use the -a option to show all installed packages from all channels. Debugging will be quite straightforward. Hosts that include PEAR rarely install more than a few often-demanded packages. Otherwise users will have to install them on their own, and they will know that they have installed a package from another channel, because it requires slightly more brainwork, even though it doesn't require much more typing.

What about using the package domain names of Java: com_example_MyPackage? Or a registration for package names, prefixes on php.net? The pear installer could refuse to install a package com_example_MyPackage if the package is hosted on a different domain. This last part will never happen. It would be an administrative nightmare, a technical nightmare, and it would bloat the installer something fierce.

However, prefixes could be the same as the suggested alias of a channel (so pear.chiaraquartet.net's suggested alias is "chiara" and after you ucfirst() it, that is the prefix). In addition, there is nothing stopping channels from using the hostname as a prefix, that would be fine. The installer does not prevent that. The point is that the installer is not the place to implement political solutions to problems. A human-based recommendation is the place to do this. The installer should be able to install anything that is out there, it is our responsibility as humans to make sure our political decision of how to name things is good. It may change too when we get wiser, which is another important reason not to restrict the installer. The technical solution that the installer takes: Thou shalt not overwrite any existing files with new ones, yea verily. is the best thing around, because then users can be assured they won't screw up their installation. It is up to coders to regulate the namespace in an intelligent fashion. pear.php.net can exercise some control by removing rogue channels that distribute malicious code or refuse to cooperate from the public listings, and even posting warnings not to use them in extreme cases. I think that we have little to fear on this front. Most PHP applications are self-contained. Those who redistribute libraries always do so with an eye to what others out there have already written. If things take a turn for the evil, then we can clamp down with a technical solution, but until I see any evidence that this is possible and imminent, I do not think it is a good idea. Greg