incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@maven.org>
Subject Re: [Possible Incubation] Apache Repo
Date Sun, 09 Nov 2003 03:32:47 GMT
On Sat, 2003-11-08 at 21:47, Stephen McConnell wrote:
> Roy T. Fielding wrote:
> 
> >> Small note - some of the participants on the repository@apache 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
jason@zenplex.com
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


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message