cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Re: Migrating to Avalon. Thoughts?
Date Wed, 12 Nov 2003 17:31:17 GMT
I cannot agree more with Stefano's comment regarding the big-O order of search and access opertions.
 We need constant time lookup and queries of information regarding the artifacts (the meta
data) as well as constant time access to an artifact's content stream regardless of how many
artifacts are contained in the repository.  This requires a heirarchy aware database.

WRT Steve's comment I agree as well, the content repository allows access to the artifact
whereas the component repository (I prefer meta data aware repo) allows access to the meta

I clearly see two domains for repository data: the relational domain and the content domain.
 Relational domain of data is separated out and modeled as queriable attributes or properties
as in directories or webdav.  The content deals with blobs of information that has some mime
type assocaited with it.  These two domains are very complimentary.

Directories and Webdav are excellent candidates for implementing fast meta data aware repositories:
because application level attributes and properties can be attached to the artifacts in directories
and webdav respectively.  Indexing of these attributes and properties leads to a fast and
efficient discovery mechanism.  Further more complex questions can be answered by the repostory
for the client if the search engine provides enough expressivity.

My $0.02,

> From: Stephen McConnell <>
> Date: 2003/11/12 Wed AM 09:31:10 EST
> To: Avalon Developers List <>
> CC:,
> Subject: Re: Migrating to Avalon. Thoughts?
> Stefano Mazzocchi wrote:
> >
> > On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
> >
> >> Just a note to let you know that there are a number of
> >> threads currently running over on the
> >> concerning the establishment of a component repository
> >> project.  After reading your email I think that many of the
> >> subjects you have addressed below are relevant to the things
> >> the Avalon crew are currently debating.
> >
> >
> > a content repository is a place where you store semi-structured data, 
> > you version it, you add metadata and you query it... it has to scale 
> > O(1) with the number of nodes (not even o(n), that's too much) and 
> > allow the smallest granularity possible (potentially, down to the very 
> > DOM node). Plusses are: granular ACL, node linking, transactionality, 
> > obvservability.
> >
> > a component repository is a library of java components, a sort of 
> > CPAN/PEAR/apt-get for java.
> >
> > Can you do a component repository with a content repository? yes, of 
> > course.
> >
> > Can you do a content repository with a component repository? no and 
> > would even be silly to try to do so. 
> Just one more variation to complete the picture - a service directory.
> A content repository can be viewed as a service.  A directory can be 
> used to discover a service provision solution (using for example a 
> repository of component descriptions).  Component descriptions can 
> reference artifacts in an content repository.  A component 
> implementation can also use a content repository as part of its 
> implementation. Etc., etc.  In this respect - the ideas of a content 
> repository and component repository are synergistic.
> Stephen.
> Stephen J. McConnell
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message