Dear Cocooners,
I've just started to take a look at the JCR (a.k.a. JSR-170) Reference Implementation from Slide, after having read the latest JSR draft, and I feel like exploring the possibilities of its usage inside Cocoon.
First thing I tried to do is an implementation of the o.a.c.components.repository.Repository, but then I started to think that it didn't make much sense. Our Repository interface is meant to provide a virtual repository API on top of different implementations (only a WebDAV impl. is available at the moment). But isn't this just what JCR is about? Wouldn't it be better if we dropped our own Repository and adopted the JCR APIs? We already have a WebDAV and a local filesystem implementation available in the RI (plus an implementation on top of a "virtual filesystem" which I haven't grokked yet). Of course, nothing prevents us from wrapping a JCR repo inside an Avalon component, if we want.
Then I thought about doing a Generator that could stream the XML representation of a JCR repo provided by the API. Should be a piece of cake as there's a method that streams it to a ContentHandler.
In order to show off what can be done with Cocoon+JCR, we could try to clone the Web frontend distributed by Day at http://jsr170tools.day.com or some part of it.
Thoughts? Questions? Volunteers?
I think that the JCR API is so low-level that a higher level poor-man dead-easy Repository interface for the repository cocoon block still makes sense, at least it will avoid you to cut/paste a bunch of similar functions over and over in your business logic handling things.
For many reasons, JCR tends to generate pretty verbose usage.
But I do think it makes sense to have general pipeline components that are able to read and write into a JCR repository anyway, but probably a Source would be better in this regard.
As for duplicating the JSR170tools, I think it would just rock, but don't expect anymore effort than writing a few lines of email, sorry.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
