Roy T. Fielding wrote:
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.
I would add one more requirement to above statement - namely "machine-friendly". There is an emerging requirement for application driven downloading that has the potential to significantly exceed the classic browser driven requirements that the ASF is addressing today. This has a direct impact on ASF costs, reliability, and utility.
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 relevant.
Hello? Avalon project requirements do not encompass repository needs, and certainly do not define them.
I don't think that I have suggested this. Avalon requirements deal with at least three layers of abstraction with respect to server side facilities. At the lowest level these requirements are rather close to the requirements you have outlined above. As far as second and third level requirements are concerned - these place functional requirements on the respective underlying facilities. My objective are rather simple - the basic facility should be a platform on which higher level facilities can be established without resorting to inefficiencies or workarounds.
I should also point out that Avalon is not alone is this respect. Other projects are evolving towards repository-awareness. Identifying and collecting those requirements (many of which are project/application specific) are central to the delivery of a basic repository that is extendible to meet the needs of a significant usage model (in terms of ASF near-term impact).
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.
Clearly yes. The work within Avalon has *done* exactly this and as a result - issues with current approaches have discovered and near term requirements have been identified. These aspects are the things that Avalon has to contribute to general model. I'll restate my earlier comment - the simplistic http + file layout assumptions "do not meet Avalon project requirements relative to repository-aware applications".
In fact this is probably the key point - is this initiative about dealing with ASF download requirements, or, does this initiative address the emerging and potentially much larger repository aware application scenario? If this is simply about safe downloading then my assertions are clearly inappropriate.
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.
Just to clarify - I completely agree that the development of tools *using* a repository are out of scope. However - these very same tools (at least those that exist today) are in my opinion *totally within scope* in terms of establishing near term requirements on the ASF and the repository solutions the ASF provides.
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!
Relative to present or short-term needs?
Please note that this is not an argumentative question. It is a question concerning the scope of this initiative and the relevance of this initiative to areas I am concerned with. I also believe that the question of scope is also rather relevant to ASF generally if near-term needs are taken into consideration.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
