Stefan Guggisberg schrieb:
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.
Why that? Isn't it just a single node with properties?
the core problem is that the jsr content model (which the ri has obvioulyI've to have a closer look at the basic jsr-170 concepts. My first impression from the given link was, that it is very complicated ;-)
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).
This would mean to completely rebuild the Slide core.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)?
If you relly want to go into that direction my advice would be to build your ri on top of the Slide core api as a first step or to let the webdavclient-lib connect to the ri.
The main point is that Slide is a compliant WebDAV server that support many protocol extensions. Can all of these WebDAV-methods be mapped to a JSR-170 based repository?
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
