Stefan Guggisberg schrieb:
Ah, that works. There seems to be a bug in the webdav layer as I can't see the uploaded files in my webdav client (konqueror). But it's all there in the content view.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:
choice. Have ahi 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
persistencehaving the jcr api on top of the webdavclient library would be certainlylook 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.
very appealing. the ri uses abstract filesystems to store its
Why that? Isn't it just a single node with properties?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 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.
Are these nodes really stored as different nodes or are they only displayed to the user as if it were many nodes?
I see. I would be great if we could achieve a 1:1 feature mapping between jcr-170 and webdav, but I still don't know if this will work. I would be bad if we would run into a situation that we currently have regarding the Slide core api.
I've to have a closer look at the basic jsr-170 concepts. My firstthe 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).
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 ;)
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.
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.
I expect some things to adjust in the area of locking, version, searching, transaction handling and notifications.
Cheers,
Daniel
cheers stefan
http://jsr170tools.day.com/crx/repository.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
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
