On Wed, 2004-11-17 at 14:31 +0000, Andy Bowes wrote: > Hi James > > Thanks for your message. > > A JCR implementation on top of Slide would definitely fit the bill for our > application. I have already made a start on creating a JCR implementation > of our internal framework to enable us to provide alternative > implementations of CMS i.e. Slide, Notes or JCR compliant. > > As the JSR170 specification has still to be finalised and there are > significant differences between the current version (which I think is v0.15) > and the public version (v0.12) I have switched my attention to polishing the > other implementations. I think the main changes are that a document can no > longer have multiple parents and the JCRQL is still basically work in > progress.
This would certainly be a problem :). > > There are some important areas that are not covered by the JCR specification > such as the API used to assign access rights to specific content > items/folders and so you would need to add your own proprietry API to map > these to the Slide/WebDav functionaility. Again, an issue. Maybe there's another specification that could be adopted for this (maybe even the WebDAV ACL spec). > > Not sure whether the best way to approach this is by creating an extra layer > above WebDav or whether it is better to use the methods in the kernal > directly. The first option would allow you to use the implementation on > other WebDav repositories but there will be a performance hit. If you take > the second track and use the Slide API directly you may also look at whether > the WebDav method classes can be refactored to use this new layer. My preference would be the WebDAV layer. It is slower, but it scales better since you aren't tied to a single hardware resource. Another item in the works is a revised API for Slide 3.0. This would mean a single API regardless of whether you were using the client or the server. > > The long term goal for our portal is to be able to migrate to a JCR > compliant repository but I reckon it will be nearly a year before the major > CMS players introduce robust implementations of the JCR specification. Our > aim is to allow our customers to select a CMS based on cost / performance > and to be able to switch CMS repositories just by reconfiguring the > application. This sounds like the goal JCR was meant to address :). -James > > HTH > > Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
