cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: [RT] Converging the repository concept in cocoon
Date Tue, 02 Dec 2003 19:19:28 GMT

Stefano Mazzocchi wrote:
> On 30 Nov 2003, at 22:04, Unico Hommes wrote:


> >
> > Yep, which is exactly where you can see the whole concept 
> starting to 
> > break.
> >
> >> the repository in the slide block uses slide directly and, mostly, 
> >> for authentication purposes... it's based on an older version of 
> >> slide,
> >
> > Hmm, really? I thought not much has changed to Slide's API 
> since 1.16.
> Uh, I looked again and you are right. Still, I don't like 
> this since it prevents me from decoupling cocoon from the repository.
> >> 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.
> >>
> >
> > I had already been thinking of resurecting some of the stuff given 
> > your recent activity on the slide dev. I've been lurking on 
> that list 
> > for more than two years and can definitely confirm that Slide was 
> > previously dead compared to recent activity.
> Hmmm, not sure it's worth the effort... 

Too late ;-) I just got the samples working with the latest Slide. 

> I think contract to 
> webdav is much more future compatible than a contract to the 
> slide API... also because we might change that contract to 
> use JCR when it's ready.

Agreed, but JCR might still take a while. And I am a bit concerned about
performance. Running Slide in-memory with Cocoon can be a good option in
some scenarios.

> > I thought JCR was supposed to be this ""? 
> > Why not just use that? Do we really need another layer?
> I think so, yes. JCR is incredibly powerful, but exactly 
> because of this power, it feels a little "low level". JCR is 
> sort of a virtual hypergranular file system with 
> multidimensions. Think of it as a persistent DOM with 
> enhanced serializing and query functionalities.
> I think you will always need a sort of "application oriented 
> API" on top of JCR... just like you need business objects on 
> top of a relational database.

I see, sounds reasonable.

> So, JCR is a sort of "JDBC for hierarchical databases". You 
> could use that directly, sure, no problem, but you end up 
> with the same troubles that you do with using JDBC directly.
> This is why I think we need a higher level "repository" API that is
> *much* easier for people to learn and use, gives immediate 
> gratification against the use of a relational database or a 
> custom file system approach and solves 80% of the content 
> storage needs.
> For that remaining 20%, you will need to connect to JCR 
> directly, but that's another story and, for now, JCR is not 
> even there so...


View raw message