hi daniel, > as far as I understand your code is at the moment completely separated > from the Slide project.
correct > IMO it would be a good idea to integrate the jcrri into the Slide > project as this would give you some more feedback on your work. There > are lots of people out there using Slide. i totally agree. > As we plan to introduce a completely new api in the Slide 3.0 release, > it might of interest to see if the jsr-170 api would be a choice. Have a > look at this thread: > http://www.mail-archive.com/slide-dev%40jakarta.apache.org/msg10230.html > So, to see if the 170-api suits our needs it would be great to have an > implementation that talks to the Slide server via WebDAV using the > webdavclient library. The upcoming Slide 2.1 release has some nice new > features as remote long term transactions and notifications, that are > also available via the client lib. having the jcr api on top of the webdavclient library would be certainly very appealing. the ri uses abstract filesystems to store its persistence model. currently you can already use the DavFileSystem (which uses the webdavclient lib) for the persistence layer. but as the jsr-170 content model is very granular and the ri's persistence model is very generic (just nodes and properties), on the webdav sevrer you'd only see a bizillion of .node.xml files with cryptic paths. adding a file through the jcr api would e.g. mean adding a node of node type 'nt'mimeResource'. that resource would be represented as 10+ separate files on the server. the core problem is that the jsr content model (which the ri has obviouly to support) is a superset of the dav model: it supports well-structured, semi-structured and unstructrued content where the dav model is resource centric (resources and collections). take a look at http://jsr170tools.day.com/crx to get an impression of the jsr/170 content model (any username will do ;). what do you think of exposing the jcr api as the slide core api (i.e. on the server)? a webdav server on top of the jcr api would imo complete the picture. we have done a quick&dirty implementation that you can try. just point your webdav client to http://jsr170tools.day.com/crx/repository. using this architecture: - jcr on the client using webdav as protocol - webdav server on top of jcr - jcr at the core would provide the following benefits: - clients could use either jcr or webdav to access the repository - java clients could access arbitrary webdav servers using jcr - webdav clients could access arbitrary jcr repositories - jcr clients could transparantly access remote and local repositories cheers stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
