cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <>
Subject Re: [RT] Converging the repository concept in cocoon
Date Sun, 30 Nov 2003 20:41:42 GMT
Stefano Mazzocchi wrote:

> I think a much better approach would be to come up with a
> interface and a few implementations that I can choose when I install 
> cocoon. This implementation would also implement and 
> provide its functionality thru a URL protocol.
> This allows:
>  - clear separation of concerns: cocoon should *NOT* be doing 
> repository stuff, which is already big and complex enough
>  - complete IoC: you choose the implementation and the implementation 
> decides what to do and how to do it. Your contract remains the same 
> (thru the source-provided URL protocol and thru the component interface)
>  - transparent polymorphism: you can have different implementations of 
> a repository... file system, webdav, CVS, JCR, ... without having to 
> change any code in your application
> Thoughts?
> -- 
> Stefano.

Looks good!  However, I think some people may not need all 5 of your 

 > Functionality I need is:
 >  1) open/save document
 >  2) create collection of documents

I think these are the core requirements of a repository.  I also think a 
simple form of document retrieval (like a Source) is necessary, but that 
might just be rolled into "open"

 >  3) attach metadata to documents (externally to them!!)
 >  4) query the repository against document metadata
 >  5) versioning (autoversioning on saving and version update)

Some people might like to get versioning and metadata a la carte.   Not 
all versioned repositories need an external metadata facility or the 
ability to query it.  I think all versioned repositories do need some 
metadata (commit logs, permissions, etc).

So what about a basic Repository interface, a specialization of it for 
metadata, and a specialization of that for versioning?

Ryan Hoegg
ISIS Networks

View raw message