Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Message-ID: <3FCAC2BB.8030801@apache.org>
Date: Mon, 01 Dec 2003 05:25:31 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: repository@apache.org
Subject: Re: subproject URI naming convention
References: <AHEMLCHGJOKOCPPFEOIHKELMHLAA.tma@netspace.net.au>
In-Reply-To: <AHEMLCHGJOKOCPPFEOIHKELMHLAA.tma@netspace.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Tim Anderson wrote:

>The URI proposal [1] doesn't provide explicit support
>for subprojects - the assumption being that these will
>be encoded in the product-specifier portion of the URI:
>
>  repository-uri = access-specifier "/" product-specifier "/"
>                   version-specifier "/" artifact-specifier
>  product-specifier = organisation "/" project
>
>Using jakarta commons as an example, there are a several possible
>naming conventions:
>
> A. http://repo.apache.org/apache/commons-cli
>    http://repo.apache.org/apache/commons-collections
>    http://repo.apache.org/apache/commons-logging
>
> B. http://repo.apache.org/jakarta.apache.org/commons-cli
>    http://repo.apache.org/jakarta.apache.org/commons-collections
>    http://repo.apache.org/jakarta.apache.org/commons-logging
>
> C. as in [B], but with "org.apache.jakarta" for organisation
>
> D. http://repo.apache.org/jarkarta.apache.org-commons/cli
>    http://repo.apache.org/jarkarta.apache.org-commons/collections
>    http://repo.apache.org/jarkarta.apache.org-commons/logging
>
> E. as in [D], but with "org.apache.jakarta-commons" for organisation
>
> F. http://repo.apache.org/jarkarta-commons/cli
>    http://repo.apache.org/jarkarta-commons/collections
>    http://repo.apache.org/jarkarta-commons/logging
>
> G. http://repo.apache.org/apache-jarkarta-commons/cli
>    http://repo.apache.org/apache-jarkarta-commons/collections
>    http://repo.apache.org/apache-jarkarta-commons/logging
>
>Of the above, [F] best matches CVS organisation:
>  http://cvs.apache.org/viewcvs.cgi/jakarta-commons/
>
>Which is the preferred approach?
>
>Another possibility is to add a mandatory subproject path segment:
>  product-specifier = organisation "/" project "/" subproject
>(mandatory so the URI can be parsed), giving:
>
> H. http://repo.apache.org/jakarta.apache.org/commons/cli
>    http://repo.apache.org/jakarta.apache.org/commons/collections
>    http://repo.apache.org/jakarta.apache.org/commons/logging
>
> I. as in [H], but with "org.apache.jakarta" for organisation
>
>This would mean a redundant directory for those projects
>with no subprojects, e.g:
>    http://repo.apache.org/xml.apache.org/batik/batik
>but would:
>. better reflect project heirarchies
>. improve navigability, as the heirarchy is not as flat
>. avoid the need to specify naming conventions for subprojects:
>  . organisation is always derived from the project domain name
>  . project is always the top level project name
>  . subproject is the subproject name, or in the absence of
>    a subproject, the same as the top level project name.
>
>Thoughts?
>

This has been quietly bugging me for the last week - but I havn't had 
the time to make a constructive suggestion. 

However - for what it worth - I think it would be better to collapse 
[organization]/[project] in a simple [path] statement.  The upside of 
this is that you have a lot more scalability with respect to nested 
subprojects, etc.  The downside is identification of the organization 
from the URL.  From my own experience I never deal with organization 
info at the url level.  That's the sort of thing I'll pull out of 
metadata bound to an artifact (e.g. jar manifest, block description, 
whatever).

This would suggest :

  http://repo.apache.org/org/apache/jakarta/commons/cli/
                        |                             |
                        |<--------------------------->|
                                        |
                                product specifier
                   (replacing the organization/project spec)


But I'm wondering if this will break things downstream?

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|