www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: repository@ awareness?
Date Tue, 11 Nov 2003 11:12:25 GMT

Leo Simons wrote:

> Justin Erenkrantz wrote:
>> Do any 'core' infrastructure people need to get involved to help 
>> guide with what's practical or not?
> yep. But I doubt you really need to get 'deeply' involved. A half-page
> explanation of what resources are and are not available should be 
> enough, don't
> you think? 

I'm probably in a minority - so don't count anything I say as an 
indicator of public opinion.

First off - the board wants human readable safe downloading. Personally 
I think this objective is of minor relevance/impact to ASF in the medium 
term. Since early 1998, the notion of repository-aware applications has 
been growing. Here in Apache its in its infancy - but clearly prevalent 
in the Java community. Maven is an early example (hit a repository for 
jar downloading to resolve n build dependencies) - Avalon is another 
example - (hit the repository and get back a class loader hierarchy).

File system - a convenient and simple solution - but should a file 
system driven approach be the basis for the next generation? My 
conclusion - no. A solution must be implementation independent - I 
should be able to map a protocol to a RDMS, LDAP, simplistic HTTP over 
file layout, even an XMI repo over IIOP if deemed appropriate.

So why a preoccupation with meta-less file system structures as opposed 
to a preoccupation with an extensible repository protocol?

Here is an example of a modern repository aware application.

$ merlin http://dpml.net/avalon-http/block.xml

The above command has executed the following:

(a) bootstrapping of a repository client
(b) resolution of repository adapter implementation
(c) downloading and installation of repository adapter and dependencies 
(meta data)
(d) bootstrapping of the repository adapter into action (meta data)
(e) downloading of block.xml using the repository adapter (i.e. protocol 
(f) validation of the downloaded artifact (meta data)
(g) construction of information about block dependencies by the local 
app (meta data)
(h) recursively downloaded artefact dependencies (meta data)
(i) local creation of a class loader hierarchy based on class loader 
assignments (meta data)
(j) created a container holding a set of composite components
(k) executed the orderly deployment of supporting components
(l) started a web server, and a set of business components, and a servlet

First time user will trigger something in the order of about 30-40 
downloads. Local system will cache information and monitor the 
repository for changes.

Step 2 - user launches a command to manage the running servlet

(a) jmx management libraries are auto-downloaded (meta data)
(b) along with a dozen commons jar file (meta data)
(c) management app invokes request on management agent download
(d) agent is deployed in a target JVM (local deployment)
(e) jnlp client completes downloading of three jar files signed using 
X509 certificates into a third JVM
(f) applet appears in users browser
(g) user updates parameters
(h) updated deployment profile is sent to remote repository (meta data)
(i) local client synchronizes local cache relative to remote repo (meta 

All of the above from one command and a few clicks of a mouse. Ok, I 
confess - we don't have of the above in place today - but do have the 
majority. This benefits significantly from a rigerouse protocol 
supporting artefact location, feature assessment (meta data), 
authentication, replication and validation. An argument that appears 
popular on repository@ is that the basic files system does not need to 
be meta-aware - i.e. no distinction between artefact and 
info-about-an-artificat. IMO it is basically a misadventure to focus so 
closely on subjects such as file system structure (the lowest common 
denominator solution). Instead – should we not be defining a protocol 
that is a transport and implementation independent? A protocol that will 
enable the functional requirements of artefact authentication, artefact 
navigation, artefact retrieval and artefact registration.

Popular arguments are that agreement on meta information associated with 
artefacts is not achivable - and yet the simple notion of named value 
pairs is a widespread abstraction. This simple notion of "the artefact" 
+ "information about an artefact" is IMO a fundamental requirement. 
After all - isn't thjis 2003 - we have the technology! Surely our 
repository spec should enable an implementation based on a files 
systems, but equally, should not restrict the potential for transparent 
replacement with alternative more advanced and efficient solutions.

Also of relavance are the economic and social impacts. A repository not 
capable of supporting or evolving towards forward looking 
repository-enabled requirements as outlined in the above scenario is 
destined to be redundant within a matter of a few years. Redundant 
because it will not be relevant to a predominant programmatic scenarios 
and redundant because it will not meet basic functional requirements.

So what are the basic requirements?

* structure - the basic notions (groups, artefacts, versions, types)
* information - properties attributable to structural items (a.k.a. 
* function - operations that can be performed on structural items 
relative to available information

Ok - shoot me down in a ball of flames!


Cheers, Steve.


Stephen J. McConnell

View raw message