Stefano Mazzocchi wrote: > > > On 30 Nov 2003, at 22:04, Unico Hommes wrote: >
<snip/> > > > > 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 "Repository.java"? > > 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... Unico
