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
