- Finishing the JSR-170 RI (including versioning, searching...)
There should be people around who are willing to help if they know that the Slide project hosts the ri.
- Cleaning up the WebDAV layer
Currently the Slide webdav-layer is containing not only the request parsing and response generation, but also some webdav specific logic.
The WebDAV can be cleaned and speeded up by separating the marshalling from the logic. I started to design some interfaces that represent the webdav-methods on java level.
By implementing these interfaces we could generate a layer of abstraction that will make it much easier to map webdav-calls to the jcrri. This would be a hard task with the current code.
These two steps can be done simultaneous.
When these steps are done we can check out how to build the full webdav-layer of top of jcrri. If this task fails, no work is lost as we can use both the jcrri and the cleaned up Slide code in future.
Another approach would be to use the jcrri as a Slide store, but this would lead into trouble as we get inconsitencies when accessing the data via both webDAV and jcr-170 api.
So I'd vote for the first approach.
Cheers, Daniel
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
curious.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
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
