From: Alan Chen <alan@...>
Date: 2001-12-07T05:55:43+09:00
Subject: [ruby-talk:27747] Re: Package Naming

On Thu, Dec 06, 2001 at 01:52:39PM +0900, Sean Russell wrote:
> Mark Hahn wrote:
> 
> > Your names could have easily been us.fed.fs.Sorting also.
> 
> Not really.  Having only one Sorting package in the entire USA Federal 
> Govornment is extremely unlikely.  In fact, each of the path levels is 
> important.  The number of people working within NRIS is a few hundred 
> working all across the country, so even us.fed.fs.nris is too big to be 
> able to avoid conflicts.  We might be able to get away with 
> us.fed.fs.nris.tools, but there are 6 different Analysis tools projects, 
> none of which share any common code, so us.fed.fs.nris.tools.etools 
> (representing one distinct set of analysis tools) is better.  Of course, 
> ETools has a client and a server component, and we could probably dump all 
> 386 classes into one big namespace under ETools, but this would be really 
> messy.
> 
> We *might* be able to put the analysis tools projects directly under the 
> NRIS namespace, but by then, the package name is already too long for 
> convenient use.
> 
> -- 
> --- SER

For me, one problem with a single naming convention is a problem
because it imposes the same amount of pkg management overhead acrross
all users. This overhead is high because it has to handle generalized
naming clashes. I'd like to see some convention that addresses
different requirements for naming overhead.  Maybe a usnet-like
approach where different branches on the root maintain their own
naming-scheme so that different needs can be addressed. Of course, this
approach is a pain if you have to learn x different naming approaches.

std.matz.decides
dns.java.naming.scheme
alt.free.for.all
enterprise.strict.naming.for.reuse

Then maybe we can have a mechanism to download packages from the
general heirarchy and install them at your site without having to
carry the full baggage of the naming scheme. Name clashes will have to
be resolved locally as they occur. If you want to preclude any possibility
of clashes at you site, import the full name. If you don't want to carry
full heirarchical names, shorten them at the site-install. (and let
the download mechanism track their global naming)

site.nris.project.subproject.lib.lib.lib (something like locally reserved IP's)
site.xml.rexml (originating from dns.org.ser.rexml.god)

Just an idle though,
--alan

-- 
Alan Chen
Digikata LLC
alan@digikata.com
http://digikata.com