incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Possible Incubation] Apache Repo
Date Sun, 09 Nov 2003 02:47:04 GMT


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.


>
> 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:mcconnell@apache.org




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


Mime
View raw message