comments are inline > -----Original Message----- > From: Daniel Florey [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 29. Juli 2004 11:29 > To: Slide Developers Mailing List > Subject: Re: author tags in proposals/jcrri > > > 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 node type 'nt:file' declares at least one child node 'jcr:content' plus a bunch of properties. 'nt:mimeResource' which could be used as the type of the 'jcr:content' child node declares more properties. use a webdav client, point it to http://jsr170tools.day.com/crx/repository and drag some files into the webdav folders. then point to browser to http://jsr170tools.day.com; you use the content browser to explore the content model that represents those files. > > >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). > > > > > I'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 ;-) i don't agree. you can keep it very simple if you want to. take a look at the 'Forum - chatterscorner' node. the node types used here model a forum with topics, threads, replies and attachments. on the other hand, you can also model very complex content, if you wish. complex models are more complicated though ;) > > >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)? > > > > > This would mean to completely rebuild the Slide core. > 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. first of all, it's up to the slide developers community to decide which path for slide 3.0 should be taken. i am not pushing in any direction. at the time when jsr 170 started the slide committers (remy, dirk, et al) thought it would be a good direction for the future version of slide and were already anticipating major changes to the slide code. when i started the implementation of the ri, i had a look at the slide api. unfortunately it didn't match my requirements, mainly because of the different content models. cheers stefan > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
