www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject catalog for optional feature and layout discovery
Date Mon, 17 Nov 2003 01:18:57 GMT
Hello,

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.

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.  Thoughts? Comments?

Alex


Mime
View raw message