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 independent)
(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 data)


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. meta-data)
* 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
mailto:[EMAIL PROTECTED]





Reply via email to