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.
Machines don't have friends and application-driven downloading is just an application performing a download (UI is not a design issue for a repository). The requirement is user-friendly, with the expectation being that user needs will evolve over time just as the interfaces will resolve over time. The immediate needs are file-based, because that is what users need right now.
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.
Whoa, you have abstract requirements? Now that's a good way to drive yourself insane.
At the lowest level these requirements are rather close to the requirements you have outlined above.
Good, then we are settled. Let's get this beast out the door with the lowest level of requirements and fulfill the others via an appropriate software development effort.
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.
Well, then they aren't higher levels, are they? And that would be an inferior design for collaboration, wouldn't it, since inter-layer processing places application requirements before those of the infrastructure. -1.
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).
No, that isn't central -- it isn't even a good idea. Please see, for example, every single "standard" for repositories that has ever been "designed", including those for ANSA's ODP, CORBA, and the JSR something-or-other that takes a simple content management problem and defines it as an ass-backwards indirect query monstrosity that nobody will ever use. We don't need that. We need CPAN, or apt-get, or fink, or something slightly more dependency aware but not so much so that we sit on our thumbs waiting for it to happen.
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.
It is about safe downloading of dependencies from a virtual repository that extends across mirrored systems on a heterogeneous, multi-organizational network. The underlying infrastructure is going to be file based because it will be replicated with rsync. I sure as hell don't want anything more complex than that at the base level. Building interfaces on top of that is trivial and not in the least impacted in terms of efficiency -- there are no methods of storing large objects more efficient than a modern filesystem. Start simple and layer on top of that.
....Roy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
