After reading a few of the conversations on the list I have come up with some
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.
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?
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.
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.