Re: Playing with the JCR RI
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto:
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.
Hmmm, I thought you were somewhat contrary to writable sources, or
did I misunderstood?
I'm talking about reading stuff out of a JCR repository.
yes, I'm not keen to writeable sources.
I don't see why there's a problem with writeable sources per se. The
problem IMO comes more from the SourceWritingTransformer, which modifies
the system state (by writing somewhere) as a side effect of the pipeline
processing.
But writeable soures used in the business logic and/or flowscript just
rock, and make it braindead easy to write data to anyone of file, cvs
repo, SQL blob, etc.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Playing with the JCR RI
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? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Playing with the JCR RI
Ugo Cei wrote: 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? I thought about that as well (don't reinvent the wheel). However I came to the conclusion that I currently don't care about JCR as much as I care about WebDAV :-) The JCR RI for sure is not (yet) as tested and proven as Slide's WebDAV library and currently I have doubts that JCR is the best API for WebDAV (sigh, time will tell). In addition I still think there is space for a more user-oriented API that works on a higher abstraction and is geared towards usage within Cocoon. I'm still planning to work on that (reworking o.a.c.components.repository.Repository (especially the exception handling ;-) and having another more user-level component operating on top of it) but I'm currently completely swamped :-( However I would be looking forward to have some JCR support/sample within Cocoon. Guido 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? Ugo
Re: Playing with the JCR RI
Il giorno 24/giu/04, alle 16:37, Ugo Cei ha scritto: 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. It *would* be a piece of cake if those methods would be not simply be implemented as: throw new RepositoryException(not yet implemented); :-( -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Playing with the JCR RI
Ugo Cei wrote: 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
Re: Playing with the JCR RI
Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto: 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. Hmmm, I thought you were somewhat contrary to writable sources, or did I misunderstood? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Playing with the JCR RI
Ugo Cei wrote: Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto: 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. Hmmm, I thought you were somewhat contrary to writable sources, or did I misunderstood? I'm talking about reading stuff out of a JCR repository. yes, I'm not keen to writeable sources. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Playing with the JCR RI
On 24 Jun 2004, at 15:37, Ugo Cei wrote: 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 am personally talking to David to try to include JAAS and transactions into the JSR-170 spec, as VNU's going to use the spec for our own repository and we need few features. So, for me, if that means tight integration between Cocoon and JCR, a big +1, but for the moment, wait for the final version of the spec :-P Pier smime.p7s Description: S/MIME cryptographic signature
