Re: [Possible Incubation] Apache Repo
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
Re: [Possible Incubation] Apache Repo
On Sat, 2003-11-08 at 21:47, Stephen McConnell wrote: 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. I have challenged you to give me a scenerio that I can't satisfy with something like the current Maven repository. Instead you drone on ad nauseum about the theoretical. Let's have a concrete example. I don't want to read your email essays and I don't want to listen to you foisting your solutions on us under the guise of trying to satisfy requirements i.e. we don't need Merlin+LDAP for the base-line repository so give it a rest because that's exactly what the initial messages sounded like to me. I clearly expressed and stated that any required information can be stored in the repository as ancillary artifacts which can be processed in application specific ways. The goal is to remain simple while being able satisfy all future requirements. I am willing to show you over course of next week with a simple example using Plexus that I can use what exists to create a Repository Aware Application. If you can actually provide a concrete use case that isn't wildly far fetched and shows that something akin to the Maven repository doesn't satisfy your requirements then I will listen to you. I am not willing to accept your long winded tomes of techno babble on the theoretical abstractions of the all singing, all dancing repository. As Roy state the repository can evolve and starting simple is definitely the right way to start. One of my favourite quotes is from Patterns for Evolving Frameworks by Don Roberts and Ralph Johnson in PLoP volume 3: quote People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstractions on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be designed of. The more examples you look at, the more general your framework will be. /quote So please lets not stray into the abstract gobblygook and stay focused on concrete examples. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: [Possible Incubation] Apache Repo
On Sun, 2003-11-09 at 00:35, Stephen McConnell wrote: Jason: I must confess that I am intrigued by your approach to collaboration! That's because you're at least as deficient as I am in the realm of collaboration. Neither you or I are any great shining examples of an ideal collaborator. You'll have to bear with me while I try to make ammends. I will try to bear with you. Following your assertion that I am droning on ad nauseum about the theoretical - combined with your follow-up with a request for specifics, I am obliged to conlude that your post concerning nauseum was simply an incorrect assertion on you part, or, your post is intended to establish an entry in a drone catalogue for the benefit of other like minded persons. While I appreciate that you are very busy working on initiative outside the scope and control of the ASF - I would *really* appreciate your guidance on this subject. Did you simply make a mistake, or are you intentions to propergate that mistake? I can't glean a single coherent sentiment in this message. But it is shorter, so we're getting somewhere. Stephen. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: [Possible Incubation] Apache Repo
It is usually unwise to mix insults with requests. However, the point of collaboration is not to obtain the civility of a collegial discussion over tea; the point is to accomplish the task. Continual discussion of issues that are not relevant to the task being collaborated upon is not collaboration -- it is being a pain in the ass. Folks, you don't have to respond to every comment, and especially not this one. If it isn't relevant, you'll get more done by just ignoring it and moving on. Roy
RE: [Possible Incubation] Apache Repo
Neither you or I are any great shining examples of an ideal collaborator. You'll have to bear with me while I try to make ammends. I will try to bear with you. Let take this at face value: someone admitting to faults, pledging to improve, asking for allowances while making even more mistakes in the interim, and offering the same in return. Few people cannot stand to improve their inter-personal communication. --- Noel
Re: [Possible Incubation] Apache Repo
Roy T. Fielding wrote: 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: I am completely aware of all of the above. What I asked was the question concerning scope relative to the ASF. The assumtions within the filesystem have a direct impact on the economics aspects and utility of deployment. Are you (representing the board) focussing on immediate or short term requirements? [ ] immediate [ ] short term Which one it is ? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
Noel J. Bergman wrote: My idea of collaboration is something *totally* different. It sure can be once you get rid of anyone who doesn't agree with you. Neither of you has the most perfect record on collaboration. Fine. Please drop it and focus on the actual task to be addressed. Sniping at each other is not going to resolve the technical issues. Noel, it seems that despite this is not the first email of this kind, the thing keeps dragging on :-/ Hence I strongly ask everyone on this list to completely ignore and snip comments and emails that are not in the scope of this discussion. *sigh* -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
