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) -
Re: [Possible Incubation] Apache Repo
Jason van Zyl wrote: On Sun, 2003-11-09 at 01:08, Stephen McConnell wrote: Jason van Zyl wrote: 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. Oh really - take a break Jason! You idea of collaboration is very clear: http://lists.codehaus.org/pipermail/plexus-dev/2003q3/03.html How does Plexus staying at Codehaus have any bearing on the notion of my collaboration? ROTFL - and you can't figure this out for yourself? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
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
> > 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
Re: [Possible Incubation] Apache Repo
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
Re: [Possible Incubation] Apache Repo
On Sun, 2003-11-09 at 01:08, Stephen McConnell wrote: > Jason van Zyl wrote: > > >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. > > > > Oh really - take a break Jason! > You idea of collaboration is very clear: > http://lists.codehaus.org/pipermail/plexus-dev/2003q3/03.html How does Plexus staying at Codehaus have any bearing on the notion of my collaboration? It is definitely an example of not wanting much to do with Avalon. It is indeed an example of me not wanting to collaborate with Avalon if that's what you're driving at but it's not evidence that shows I can't collaborate. Collaboration on the on notion of containers is quite healthy, vibrant and diverse at Codehaus which is why Plexus will stay there. > My idea of collaboration is something *totally* different. It sure can be once you get rid of anyone who doesn't agree with you. Anyone can go look in the Avalon Dev archives and see for themselves the examples of your collaborative efforts. Discussion between yourself and various members of Avalon, present and past, were far from amicable and quite the antithesis of a true collaborative effort. > 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
> 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
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
Jason van Zyl wrote: 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. Oh really - take a break Jason! You idea of collaboration is very clear: http://lists.codehaus.org/pipermail/plexus-dev/2003q3/03.html My idea of collaboration is something *totally* different. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
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
Jason van Zyl wrote: On Sat, 2003-11-08 at 23:18, Stephen McConnell wrote: Jason van Zyl wrote: 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. Jason: Look around you - take a look at things you involved with. I've already provided you with examples where the simplistic http over a maven style file system layout breaks. Which one's were those so we can record them here? Jason: I must confess that I am intrigued by your approach to collaboration! 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? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
On Sat, 2003-11-08 at 23:18, Stephen McConnell wrote: > Jason van Zyl wrote: > >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. > > > > Jason: > > Look around you - take a look at things you involved with. I've already > provided you with examples where the simplistic http over a maven style > file system layout breaks. Which one's were those so we can record them here? > You have already provided me with the > details of workarounds that the Maven platform incorporates to address > these inefficiencies. There is a bigger picture. That picture is based > on the collection of the requirements from repository-enabled > applications - a set of requirements that you seem determined to reject. It's a set of requirements I embrace. I too wish to write applications that use a repository but I don't believe it's any more complicated that a file-based repository accessible via http. I have yet to see a concrete example from you that shows otherwise. -- 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
Jason van Zyl wrote: 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. Jason: Look around you - take a look at things you involved with. I've already provided you with examples where the simplistic http over a maven style file system layout breaks. You have already provided me with the details of workarounds that the Maven platform incorporates to address these inefficiencies. There is a bigger picture. That picture is based on the collection of the requirements from repository-enabled applications - a set of requirements that you seem determined to reject. We can address those concerns with an open mind (a.k.a. a process of collaboration and mutual respect) or we could follow your approach to consensus building. While I'm very confident that you believe that your conclusions meet the present and near-term ASF requirement, I and others have different opinions. Should you wish to explore that area more constructively - I am very confident that a sustained effort by you towards the consideration and appreciation of the opinions and experience of others will go a long way in justifying your potential contribution to this subject. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
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: 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. 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
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 concer
Re: [Possible Incubation] Apache Repo
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 relevant. 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! Roy
