We definitely need to start walking through features point by point to map JCR and webDAV, but, as a high level comment, I think most of the mismatch is manageable. For example, JCR takes a broad view of authorization and it would be possible to creat a JCR implementation with, for example, policy-based access controls. It's also possible to do access control lists that map well with webdav.
So - it should not be hard to make a webdav-centric JCR by design, (or perhaps keep a general design and make webdav compatibility a configuration option). It could be hard to provide webdav on top of *any* JCR but that's not really Slide's issue. (Similar issues exists elsewhere - JCR allows multivalued properties which webdav doesn't support, but you can limit the JCR content model to disallow multivalued properties (or define your mapping through webdav)). There could still be gotcha's, but in general JCR has followed the model of exposing server-managed information through properties much like webdav and a JCRclient-webdav-JCRserver model has certainly been implicit the thinking. If there are specific issues that can be identified quickly, I don't think JCR is quite final (through public review but not yet at a draft final spec) - there may still be ways to fix things. Jim ----- Original Message ----- From: "Daniel Florey" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, August 03, 2004 8:20 AM Subject: Re: Slide 3.0 long term plans > Stefan Guggisberg schrieb: > > >Daniel Florey wrote: > > > > > > > >>Yes, I've seen this and it looks very promising. But as far as I can > >>tell, it will be much more complicated to build the deltaV, acl, > >>transaction, notification and dasl specs on top of jsr-170. > >> > >> > > > >it's certainly not trivial but i don't see why it shouldn't be possible. > >all required building blocks are there in JSR 170: versioning (closely > >sync'ed with JSR 147), observation, JTA support, observation, search... > > > > > > > To find out if it is possible to build the complete webdav layer on top > of jsr-170 is to give it a try. I don't know much about jsr-170, but I > didn't find the following webdav-features in jsr-170: > Locking: > - timeout of locks > Acl: > - handling of principals > - aggregation of actions (permissions in jsr terms) > deltaV: > - Baselines, Activities... > > >>I see. But IMO it is a key feature of the 3.0 release to have a single > >>API that can be used on client and server side (see 3.0 design approach > >>in the wiki). So how can we achieve this when using JSR 170? Just curious. > >> > >> > > > >my idea would be to expose the JCR api on the server and on the client. > >i've implemented a transparent RMI layer for the JCR api for a previous > >version of the ri. the client side JCR implementation could of course use > >any transport protocol, that's up to the implementation. > > > > > I think this is a fundamental different approach. > Currently the Slide project is WebDAV-centric. There is a mature > testsuite that runs with different webdav-servers, a webdav commandline > client etc. > The goal is to have a first class WebDAV-server that supports as many > aspects of the WebDAV protocol as possible. If we can achieve a broader > WebDAV-support, we can use the growing number of nice WebDAV-clients > around. If subversion is getting more WebDAV-compliant and we are > implementing more of the deltaV features, we can even use the fine > subversion clients. > A lot of people are using Slide to make their content repository > WebDAV-enabled. So the bridge from Slide to legacy repositories should > be simplified. > IMO jsr-170 should become the default repository/store if it supports > all the WebDAV features. > So, to find out how to proceed, we need an expert who knows all about > WebDAV *and* the jsr-170 spec... > > Cheers, > Daniel > > >WebDAV could IMO be used as an alternative for accessing the > >resource-centric > >content in the repository. > > > >regards > >stefan > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
