cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Norén <m...@alma.nu>
Subject Re: [RT] Converging the repository concept in cocoon
Date Mon, 01 Dec 2003 12:04:30 GMT
Stefano Mazzocchi wrote:

> I'm working on Doco and I finished my first phase: I have a repository 
> that I like and does what I need. It's Slide, in case you haven't 
> noticed ;-)
>
> So, now I have a WebDAV/DeltaV/DASL/ACL repository and I want to 
> connect to it.
>
> There has been a lot of work in the area of "Repository API" lately, 
> both inside and outside cocoon.
>
> Cocoon currently hosts four different repositories concepts:
>
>  1) two in the linotype block
>  2) one in the slide block
>  3) one in the repository block (which is a refactoring of the 
> SourceRepository in linotype)
>
> the linotype repository is a big time hack: it does what linotype 
> needed, but it's not reusable outside (concerns overlap in its 
> interface). The SourceRepository is an implementation of the linotype 
> Repository over a source instead that over a file system. While nicer, 
> it inherits all the problems of the original interface. It does 
> versioning but it doesn't do properties or property querying.
>
> the repository in the slide block uses slide directly and, mostly, for 
> authentication purposes... it's based on an older version of slide, 
> doesn't handle versioning, doesn't handle file properties. It's based 
> on actions, generators and transformers. To me, looks old and the need 
> to have the repository on the local machine (and keep it opaque to the 
> outside world) makes it impossible to use in what I need. 

Not entirely true,  there is some versionable stuff in there, and it 
uses a CVS version of slide2.0 I think. We´ve been using it for a simple 
CMS-solution.
We´re using a relational backend (mysql) instead of  the 
XMLFileDescriptorStore, we store both properties and content and they 
are all versioned.
But if the C2 team could come up with something better I would be more 
than happy to switch to it :)

>
>
> the one in the repository block is the cleanest one, but IMO, its 
> design is backwards. I'll explain what I mean in a second.
>
> For now, I think it's a must that, just as we did with forms, we take 
> a look at the various approaches and choose one to follow and ignore 
> the other ones.
>
> I think the repository block is the best effort, but it needs 
> substantial redesign.
>
>                                          - o -
>
> First of all, let me introduce what I mean with a "repository".
>
> A repository is a place where I store my content.
>
> Functionality I need is:
>
>  1) open/save document
>  2) create collection of documents
>  3) attach metadata to documents (externally to them!!)
>  4) query the repository against document metadata
>  5) versioning (autoversioning on saving and version update)

Things that could prove useful:

6) observation - add listeners to specific events in the repository 
based on both the type of event and on the location in the repository.
7)  visitable nodes in the tree - do batch processing on nodes in the 
repository, etc. For example to set specific properties on nodes in a 
specific branch.

 From a flow (or more correctly from a rhino) perspective I´ve been 
thinking about some kind of  scriptable node to make it possible to 
script certain tasks against the repository. This could of course be 
used from the flow-layer as well.
Anyone else out there that´s been experimenting with this idea?

I´m aware of the fact that these functionality requirements are not the 
first to consider when converging the repository concept in Cocoon, but 
I still think they can be useful. :)

/Regards Mats





Mime
View raw message