> 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.
> 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

I'll work something up in the Wiki TODOs section and transfer any pros/cons


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?



Reply via email to