RE: [proposal] URI Syntax - v0.2
I changed organisation to name-segments to support structures using reverse-FQDNs e.g: http://repo.apache.org/org/apache http://repo.apache.org/org/tigris http://repo.apache.org/com/sun while maintaining support for single segment organisation names e.g: http://repo.apache.org/oracle See the comments regarding groupId in the original proposal for background: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=308 From a tool perspective, it can unambiguously locate a project when given inputs of: org.apache - must replace . with / before performing lookup org/apache oracle The implication of this is that generic tools can't parse the URI and determine what is part of the product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim From: Anou Manavalan [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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/[EMAIL PROTECTED] ache.orgms 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
Re: [proposal] URI Syntax - v0.2
Tim Anderson wrote: From a tool perspective, it can unambiguously locate a project when given inputs of: org.apache - must replace . with / before performing lookup org/apache oracle The implication of this is that generic tools can't parse the URI and determine what is part of the product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim I think easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
From: Nick Chalko [mailto:[EMAIL PROTECTED] Tim Anderson wrote: From a tool perspective, it can unambiguously locate a project when given inputs of: org.apache - must replace . with / before performing lookup org/apache oracle The implication of this is that generic tools can't parse the URI and determine what is part of the product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim I think easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. -Tim
Re: [proposal] URI Syntax - v0.2
Tim Anderson wrote: ink easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. I think I see, A tool only needs to be able to generate a URL given the org, project, version, and artifact name. No need to be able to parse a given URL back into it parts. I think I can live with that. -Tim smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. There is a requirement that repositories work (at some minimum level) without metadata, especially since we aren't specifying metadata. Without a parsable URI (or parsable URL) how do tools read a repository to do things like clean oldest nightly/snapshot, but leave all releases, download latest release or even the basics determine/display contents, show basic contents (irrespective of version/type). Adam, and how is said tool going to start in the first place? Without meta-data, there is a limit to what the tool can do. Basically, it would have to operate relative to the URL provided to it. As for the particular examples you gave, those carry semantic meaning that would require more specification that is contained in the URI syntax. Although those would be desirable, I don't know that we want to including that kind of semantic specification in the URI. If we are proposing a standard, there has to be a valid purpose for it -- and having a standard that isn't structured for computer processing seems setting the bar pointlessly low. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. --- Noel
Re: [proposal] URI Syntax - v0.2
Noel wrote: Adam, and how is said tool going to start in the first place? Without meta-data, there is a limit to what the tool can do. Basically, it would have to operate relative to the URL provided to it. My input here is primarily based on writting Ruper (http://www.krysalis.org/ruper), a tool that attempts exactly what I said. It is given links to repositories (local or remote), it read the repositories and allows queries into that repository based on attributes of the resources. It does this by parsing the URLs. You don't have to like the tool, I'm not trying to push the implementation, I'm just giving you experiences from that tool. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't care whose implementation gets used, I feel that these capabilities are so powerful that they ought consist of a minimum bar for apache. Sure, it isn't going to be a 100% generic tool for all cases, but apache is doing this for apache. Let the tools lead and the users (our own committers) can chose to follow. Once, along came a browser and sooner or later folks were converting their documents to HTML 'cos the benefits outweighed the resistence to change. I'm saying that we can't enforce things, but if we make the benefits sufficiently worthwhile transition easy folks then most folks will follow. Again, this tool works today on over 95% of the contents of the Maven repository without any spec. We could achieve this. A nice simple IDE plugin can update a project and download files with or w/o user intervention, e.g. http://www.krysalis.org/ruper/eclipse/index.html. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. Aren't you saying that metadata can allow a remote tool to instrospect? Yes, I agree, this has nothing to do with an unparsable URI scheme. The URI scheme is generally fine, but if we aren't addressing metadata (almost impossible) why set back tools that mine metadta from URIs? It works today, why would we force a step backwards? [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. True, my bad, I go carried away with my argument, the tool I am familiar with, and my own dislike of stale software links. You could have the client tool be told the resource/URI by the user, and do the download/verification, yes. That said, I don't think it buys the user enough, they have to browse/locate stash the URI in some local config. I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot (e.g. http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. I don't mind being alone in my views, but I ask again -- if we don't set the bar higher than a one-way URI for download, why write a spec at all? I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. regards Adam
RE: [proposal] URI Syntax - v0.2
From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] snip/ You could have the client tool be told the resource/URI by the user, and do the download/verification, yes. That said, I don't think it buys the user enough, they have to browse/locate stash the URI in some local config. I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot (e.g. http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. I don't mind being alone in my views, but I ask again -- if we don't set the bar higher than a one-way URI for download, why write a spec at all? I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I believe this is possible using the current proposals. If tools follow these when deploying artifacts, a user can can say go get me the latest formal xerces build. That said, some configuration will always be required, whether it be like maven's project.xml dependency resolution, or some other scheme. The proposals aim to avoid users explicitly using URIs. Users should be able to supply a set of criteria and the tools be responsible for constructing the URI. -Tim
RE: [proposal] URI Syntax - v0.2
My input here is primarily based on writting Ruper You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] I'd like to say go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot That to me, is useful. Absolutely. But that may require something more than the URI schema. :-) I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) --- Noel
RE: [proposal] URI Syntax - v0.2
From: Noel J. Bergman [mailto:[EMAIL PROTECTED] My input here is primarily based on writting Ruper You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. The common build version specifier proposal does add structure to the version, but doesn't enable tools to determine if one version is older or newer than another. A tool could reasonably assume that version 1.0 2.0 but this is only valid for projects which follow numeric versions. For those projects which love codename versions (e.g, chicago, delta), no assumptions can be made. -Tim
Parsable URI (Re: [proposal] URI Syntax - v0.2)
Noel wrote: You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? No Neol, I'm not that emoition, I meant it dispassionately and without inference, maybe it just read differently. That was more 'one' doesn't have to like it. [I know this list has (in the past) slipped into implementation codebase factions, and I was hoping not to encourage that.] So perhaps I should've writen ... One doesn't have to like this tool/implementation, but the results are valuable at layer 1. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Ruper parses all the attributes of the resources, including the version, and either do (pchar) string comparisons or (in versions case) structured comparisons. Much as there are a few different flavours of a versions they pretty much fall into a parsable pattern. Ruper (through Version) strictly parses the string in a number of different ways (known formats) until one matches. Again, the most important aspect of parsing the URI is knowing what is separated from what, that this pchar is a version, this pchar is a type (or whatever). If values can by groked within that, great, if not, it is still Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. We all agree to layers, but I am testing what are the minimum things we'll accept for layter one. I beleive that the repository needs to be 'tooling readable', hence the URI needs to be parse, the other aspects (can an attributed be fully groked) can come later. Again, I need to get to the wiki to put a proposal and pros/cons, I'll try next week. Absolutely. But that may require something more than the URI schema. :-) But if it doesn't have to, should it? I'm trying to determine what we ought will accept at the lowest level. I think clean up is important, I like the other aspects. I agree that much should be done via metadata (e.g. dependencies) however writting potentially shared/conflicting files to a repository is a scary step, and I'd like to see how much we can do with atomic artefacts. I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) Yes, and we are doing layer one -- without metadata, we still need to determine our minimum expectations. If URI is this contentious/involved, I could see metadata as being a long drawn out process one we don't agree on as a whole. Maybe this first layer is the hardest, but I'd like it to be the one giving the most rewards so we aren't all sitting waiting for metadata. regards, Adam
RE: Parsable URI (Re: [proposal] URI Syntax - v0.2)
The URI proposals so far specify URIs which are just as parseable as those currently in use by maven's repository [1]. The only caveat is that they need to be parsed from right to left, as the organisation [2] part of product-specifier cannot be separated from the directory part of access-specifier, without prior knowledge of the repository structure. E.g: if a repository has its root at: http://www.apache.org/repository And the organisation of a project is: org/apache And the project name is: commons-cli The URI: http://www.apache.org/repository/org/apache/commons-cli needs to be parsed from right to left to determine that the project is commons-cli. Without knowing that the repository has its root at: http://www.apache.org/repository; the organisation cannot be determined. Like maven's repository, which doesn't impose any version naming convention, tools trying to parse the URI need to make guesses as to which version is older or newer. -Tim [1] http://www.ibiblio.org/maven [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Noel wrote: You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? No Neol, I'm not that emoition, I meant it dispassionately and without inference, maybe it just read differently. That was more 'one' doesn't have to like it. [I know this list has (in the past) slipped into implementation codebase factions, and I was hoping not to encourage that.] So perhaps I should've writen ... One doesn't have to like this tool/implementation, but the results are valuable at layer 1. It allows you to query what is there, query and capture oldest resources [and do a delete/clean], and download newest, etc. How does it know what OLDEST means? I see that Tim is trying to add some more structure, so maybe he's thinking that we can restrict the URI space so that a restricted notion of version assures an automatable concept of succession. Ruper parses all the attributes of the resources, including the version, and either do (pchar) string comparisons or (in versions case) structured comparisons. Much as there are a few different flavours of a versions they pretty much fall into a parsable pattern. Ruper (through Version) strictly parses the string in a number of different ways (known formats) until one matches. Again, the most important aspect of parsing the URI is knowing what is separated from what, that this pchar is a version, this pchar is a type (or whatever). If values can by groked within that, great, if not, it is still Some find such a tool useful, I'd like to believe that apache users (admins and external users) would find it useful. I don't disagree. I simply said that if you view the repository solution as a layer of specifications, the lowest layer can be a syntax that does not require semantics such as an automatable concept of succession. If we need that, we can add it either by a convention within the URI space, or by other means. We all agree to layers, but I am testing what are the minimum things we'll accept for layter one. I beleive that the repository needs to be 'tooling readable', hence the URI needs to be parse, the other aspects (can an attributed be fully groked) can come later. Again, I need to get to the wiki to put a proposal and pros/cons, I'll try next week. Absolutely. But that may require something more than the URI schema. :-) But if it doesn't have to, should it? I'm trying to determine what we ought will accept at the lowest level. I think clean up is important, I like the other aspects. I agree that much should be done via metadata (e.g. dependencies) however writting potentially shared/conflicting files to a repository is a scary step, and I'd like to see how much we can do with atomic artefacts. I feel we have the potential to win big, and I'd like the ASF Repository to be a step forward towards these goals, not a step backward. I agree. But one layer at a time. :-) Yes, and we are doing layer one -- without metadata, we still need to determine our minimum expectations. If URI is this contentious/involved, I could see metadata as being a long drawn out process one we don't agree on as a whole. Maybe this first layer is the hardest, but I'd like it to be the one giving the most rewards so we aren't all sitting waiting for metadata. regards, Adam
Re: [proposal] URI Syntax - v0.2
Digesting each section slowly, Its great idea to make Artifact Specifier to be opaque to give way to different languages, but I am not sure about the Version Specifier. Version Specifier can be considered as language independent and allowing different best practices in there would make the repository unordered and could confuse the users. 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/xorg/xyz/release/1.2 http://repo.apache.org/yorg/abc/v0.9-beta/abc.. thoughts ? regards, -Anou From: Tim Anderson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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/[EMAIL PROTECTED]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
Tooling (was Version Specifier in Re: [proposal] URI Syntax - v0.2)
Its great idea to make Artifact Specifier to be opaque to give way to different languages, but I am not sure about the Version Specifier. Version Specifier can be considered as language independent and allowing different best practices in there would make the repository unordered and could confuse the users. I know of opinions on both sides. Some say we can't dictate, so best practices are the best we can expect even they'll be loose. Others say, we can't achieve conformity unless we try -- and that tools can't process totally unstructured opaque data. I think the questions become (building upon each other): 1) Ought the URI be uniquely (unambiguously) parsable [i.e. things such as your '-' not '/' proposal.] 2) Ought the URI be considered 'metadata' itself structured? 3) Is the goal for the repository to be tools processable [even without metadata]? I'll work something up in the Wiki TODOs section and transfer any pros/cons there. --- One last comment on tools-based verses human-based. We are discussing version in filename so it's version is identifiable once download from the repository. It occurred to me that we are likely assuming a dumb client (a human w/ browser perhaps) in that thought. Nothing is to stop tools downloading an unversioned filename and adding -[version] to the end as it writes it to disk. Since we can likely assume that many humans have bad habits of not doing verification checks of the contents of repositories that they download with a browser, ought we actually weight our cogitations towards tooling that can browse/select/download/verify. Note: I'm not talking implementation, nor any tool, and I'm definitely not saying disallow the human user use case, I'm just saying focus on tooling. IMHO tooling (built upon certain levels of repository consistency) make the repository@ venture more than just a re-organization of file systems, and allow us to scale this and save a lot of wasted human effort. It seems a critical goal to me. Thoughts? regards Adam
