incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: [Possible Incubation] Apache Repo
Date Sun, 09 Nov 2003 06:52:13 GMT
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message