> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, 17 November 2003 12:19 PM
> To: [EMAIL PROTECTED]
> Subject: catalog for optional feature and layout discovery
> After reading a few of the conversations on the list I have come
> up with some ideas.
> First Jason mentioned the use of decorations to embellish the
> functionality of the repository. After some thought I will have
> to agree even though I did not at first. Keeping the repository
> simple is a good thing.
> Now there were discussions with Tim regarding the layout of the
> repository and how the URL was to be designed. Then Steve talked
> about using meta data (the notion of associating
> attributes/properties with artifacts). I think this can be used
> as meta data but that's one application of it. I think these
> attributes can be used for just about any application.
Steve's ideas tie in neatly with WebDAV's support for resource
attribution. WebDAV is out of scope tho, I think.
> So how do we enable a flexible repository that allows clients to
> discover the optional services/features implemented as decoration
> on the repository? Also how do we enable any kind of regular
> repository structure so we do not have to restrict the layout of
> the repository?
I don't think restricting the repository structure is a bad thing. It:
. enables artifacts to be located in one lookup
Any discovery mechanism is going to require multiple lookups.
. enables users browing the repository to locate artifacts
without examining a catalogue to determine where they are
. can still support any kind of meta-data (or decoration)
Tools which do not understand the meta-data simply ignore it.
. leads to simpler tool implementation
> If the repository published a simple manifest or catalog of sorts
> in a fixed location so client APIs (in any language) can access
> it, then we can use this to store the following:
> 1). List of optional decorations offered by the repository
> 2). List of directory structure and naming rules
> 3). Miscellaneous seed information required to negotiate with the repo
> 3 is just filler cuz I did not want to have just two points ;-).
> Ok the list of decorative services, features or what have you
> describe the optional functionality offered by the repository.
> One such feature may be the use of attributes for associating
> relational information with a repo artifact. The potential
> features are limited only by the imagination. Just the other day
> I was using xdelta (the binary diff tool) and it occured to me
> that the repository could offer xdelta generation on the fly for
> applications that want to upgrade but use diffs instead of
> pulling down massive binaries. This is just an idea and its here
> to show how pleasantly carried away we can get with decorations
> so don't interpret me as trying to add it to the repository ;-).
> The point is with this catalog we can publish these features -
> the means to do that can be debates but we should not spend time
> on debating what features to add. At the end of the day this is
> left to the discretion of the user. We just need to allow for
> all the possibilities.
> Now in terms of #2 we can make the structure of the repository
> and the naming conventions used user definable by including
> naming and structure rules for the directory layout of the
> repository. These rules tell clients how to navigate the
> repository to get at the artifacts they may be interested in.
> And the published decorations tell the client how it can take
> advantage of optional services offered by the repository.
The only advantages I can see for supporting user defined
naming conventions and structure are:
. unrestricted artifact URIs
. the possibility to retrofit ASF repository onto an existing
This is at the cost of:
. predictable repository structure
. simple tool implementation
. ease of repository navigation
> I'm also trying to concieve of how client API's can selectively
> leverage these feature using plugable repository feature
> extensions. Also trying to get a feel for what this might look
> like and the use cases.
> These are just some ideas that have sparked in my head as a
> consequence of the recent activity on the list. Thought I'd put
> them out to be discussed. Thoughts? Comments?
I'm not against pluggable repository features, but I can't think
of too many uses for it. The only one which springs to mind is
a search facility, but it needn't be pluggable.
Also note that WebDAV and DeltaV provide limited search facilities.