Small note - some of the participants on the [EMAIL PROTECTED] are
discussing the actual requirements - which from my (and other) point(s)
of view go beyond a file-system http protocol cut-and-dried implementation
solution. Some consider this area to be much more than an HTTP download
handler. In fact - if the scope of a repository model were limited to
that then would would be missing a really big opportunity to do this in
a way is of real value to multiple projects. Yes - you can assume some
simplistic models down low - but hopefully this is not just about
plumbing but also about addressing the requirements across different
abstractions that will ultimately ensure that semantic assumptions are
consistent across multiple repository-enabled applications.

The requirement is that ASF-owned software be distributed in an efficient
(for our costs), reliable (for our maintainers), and user-friendly way.
Feel free to consider any number of designs that may accomplish that
requirement, but don't mistake a design opinion for a requirement.
In particular, do not under any circumstances hold up implementation
of the repository in pursuit of perfection -- a current implementation
can be replaced at any time we see fit.

Just trying to clarify, is this correct?

I hope not - it would not meet Avalon project requirements relative to
repository-aware applications. I much prefer Roy's terminology "a single
storage facility to look like a repository with multiple interfaces".
Roy's statement *does* encompass the scope of requirements that I see as

Hello? Avalon project requirements do not encompass repository needs, and certainly do not define them. Avalon users might prefer a given interface to the repository, which I assume the Avalon community is more than capable of defining and developing on their own. The commonality that is required by repository is determining the easiest way for all of our projects to provide artifacts and their authenticity-proving signatures such that the general public can get what they want, when they want, at a minimum cost to us. The tools that retrieve from the repository are not within its scope.

Anything (and I do mean anything) beyond that is a software project
that the ASF has not authorized, and certainly won't be developed here
unless it is within a PMC.  People are certainly welcome to propose
such a project on incubator, but that is not the repository project.
Repository is a task to be accomplished!


Reply via email to