www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anou Manavalan" <anou_m...@hotmail.com>
Subject Re: [proposal] URI Syntax - v0.2
Date Fri, 14 Nov 2003 15:27:34 GMT
Tim,

This is very nicely laid out.

I have one little suggestion,
In the Product Specifier,  can the organization be made as just  
name-segment ? This avoids the confusion of / separator that separates the 
main things like the orgainization / project with / separating the 
organisation itself.

I mean, replace . By - instead of /  - since / is used as the main 
separation.

Instead of this, where it is hard to say where the org ends and where the 
project starts, you sure can differentiate it, but
http://repo.apache.org/org/apache/commons-logging

this makes more sense as org / project
http://repo.apache.org/org-apache/commons-logging


regards,
-Anou

>From: "Tim Anderson" <tma@netspace.net.au>
>Reply-To: <tma@netspace.net.au>
>To: <repository@apache.org>
>Subject: [proposal] URI Syntax -  v0.2
>Date: Fri, 14 Nov 2003 16:39:06 +1100
>
>This version replaces v1.0:
>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
>gNo=308
>
>
>Overview
>========
>
>The key aims of this proposal are:
>. language and artifact neutrality.
>   It should be possible to support multiple languages and
>   their artifacts, not just java.
>
>. it should be possible for users to easily navigate
>   the repository and locate artifacts, including
>   jars and release distributions.
>   Compare this with the existing approach of separating
>   release distributions (http://www.apache.org/dist/) and jars
>   (http://www.ibiblio.org/maven).
>
>. it should be possible for tools to construct a URI
>   to locate an artifact using a set of known criteria
>
>Artifacts
>---------
>
>All files in the repository are artifacts. There is no distinction
>between artifacts and meta-data. Any relationships between artifacts
>is determined by supporting tools.
>
>
>Repository URI Components
>=========================
>
>An absolute repository URI is written as follows:
>
>   repository-uri = access-specifier "/" product-specifier "/"
>                    version-specifier "/" artifact-specifier
>
>
>Access specifier
>----------------
>
>The access specifier determines the scheme, authority, and optional
>repository directory prefix. There is currently no requirement for
>ftp, scp or file based access - only http is supported:
>
>   access-specifier = http-access-specifier
>   http-access-specifier = "http://" authority "/" [directory "/"]
>   directory = path_segments
>
>   (authority and path_segments are per 
>http://www.ietf.org/rfc/rfc2396.txt)
>
><directory> is used when the repository cannot be located at
>the root of an absolute URI.
>
>URI examples:
>   http://repo.apache.org/
>   http://repo.apache.org/pub/repository
>
>
>Product specifier
>-----------------
>
>The product specifier specifies the organisation and project:
>
>   product-specifier = organisation "/" project
>   organisation = name-segments
>   project = name-segment
>   name-segments = name-segment *( "/" name_segment)
>   name-segment = nchar+
>   nchar = alphanum | escaped | "_" | "-" | "!" | "~" | "@" | "&"
>
>   (alphanum and escaped are per http://www.ietf.org/rfc/rfc2396.txt)
>
><organisation> is the organisation name. It is arbitrary,
>but should be globally unique. It could be the domain name,
>or reverse domain name, with "." replaced by "/", e.g:
>   "sun/com", "org/apache"
>or simply the name of the organisation, e.g "oracle".
>
><project> is the project name. It is unique within an organisation.
>E.g, "ldap", "jndi", "maven", "commons-logging".
>
>URI examples:
>   http://repo.apache.org/org/apache/commons-logging
>   http://repo.apache.org/sun/jndi
>
>
>Version specifier
>-----------------
>
>The version specifier specifies the version of the project:
>
>    version-specifier = name-segments
>
>For the purposes of this proposal, version-specifier is opaque -
>its format is determined by language and deployment best practices.
>
>Some possible examples include:
>  "1.0", "v0.9-beta", "nightly/20031113", "latest", "release/1.5.4"
>
>URI examples:
>   http://repo.apache.org/apache/commons-logging/1.0
>   http://repo.apache.org/apache/commons-logging/1.1
>   http://repo.apache.org/apache/commons-logging/latest
>   http://repo.apache.org/apache/ant/release/1.5.4
>   http://repo.apache.org/apache/ant/nightly/20031113
>   http://repo.apache.org/apache/commons-cli/nightly/1.0/20031113
>   http://repo.apache.org/apache/commons-cli/nightly/2.0/20031113
>
>
>Artifact specifier
>------------------
>
>The artifact specifier uniquely identifies an artifact within a
>project version:
>   artifact-specifier = name-segments
>
>For the purposes of this proposal, artifact-specifier is opaque -
>its format is determined by language and deployment best practices.
>
>Some possible examples include:
>  jars/commons-logging-1.1.jar
>  binaries/linux/httpd-2.0.40-i686-pc-linux-gnu-rh73.tar.gz
>
>URI examples:
>
>http://repo.apache.org/apache/common-logging/1.1/jars/commons-logging-1.1.ja
>r
>   http://repo.apache.org/apache/httpd/2.0.48/docs/httpd-docs-2.0.48.en.zip
>   http://repo.apache.org/apache/ant/1.5.4/KEYS
>
>
>Rationale
>=========
>
>Of the URI components:
>. <access-specifier> and <product-specifier> are common accross
>   all languages and deployments.
>. <version-specifier> is subject to language or deployment
>   best practices
>. <artifact-specifier> is subject to language, deployment, artifact, or
>   project best practices
>
>It is envisioned that there will be different repository deployment
>and query tools developed for each language. A generic tool cannot
>be written without providing supporting meta-data, which is outside
>the scope of this proposal.
>
>Projects should be able to deploy arbitrary artifacts to the
>repository, whether they be for end-users, or meta-data (e.g, maven's
>project.xml). Tools should ignore any artifact they don't understand.
>
>To ensure interoperability between language-based tools, best-practice
>guidelines need to be drawn up for each supported language and deployment
>scenario.
>
>
>Appendix
>========
>
>Changes from v0.1
>-----------------
>
>. repository-uri changed from:
>     access-specifier "/" product-specifier "/" artifact-specifier
>   to:
>     access-specifier "/" product-specifier "/" version-specifier "/"
>     artifact-specifier
>
>. product-specifier changed from:
>     organisation "/" project "/" version
>   to:
>     organisation "/" project
>
>. organisation changed from:
>     *pchar
>   to:
>     name_segments
>
>. project changed from:
>     *pchar
>   to:
>     name_segment
>
>. version renamed to version-specifier, and is now opaque
>
>. artifact-specifier is now opaque
>
>

_________________________________________________________________
Frustrated with dial-up? Get high-speed for as low as $26.95.  
https://broadband.msn.com (Prices may vary by service area.)


Mime
View raw message