8 Oct
2008
8 Oct
'08
9:21 p.m.
Asiri Rathnayake wrote:
Hi Devs,
I think it's fair to call our current webdav implementation a generic webdav
server implementation for xwiki because it directly utilizes the xwiki core
and presents a custom webdav view of an xwiki repository for users. At the
time we began working on webdav, this is the only option we had. But with
the xwiki-jcr component in town we can have a different sort of a webdav
server which is kind of a ready made one which is capable of exposing any
jcr repository via webdav (ex. jackrabbit jcr server). Now the conflict is
now we have two webdav server implemntations, what are we going to do now ?
Please excuse me for any errors since my current understanding of JCR is
poor.
comparison:
generic webdav:
pro:
already is & works
generic: works on any storage systems.
jcr-based webdav:
work by get/put all info directly in JCR repository, without any
additional info, without bothering the core.
pro:
minimal effort needed for basic features.
contra:
works ONLY on JCR implementations.
possible problems:
authentication & rights:
jcr uses own authentication system. But we could try to intercept
request and check rights by self.
direct write via webdav ignores the core: need to notify the core via
jcr observations (for cache, versioning) => complicates storage system.
careful jcr hierarchy design is needed. jcr hierarchy is directly
mapped to webdav urls. But we could try to rewrite/filter some requests.
I'm not sure all webdav features will work as expected. Testing needed.
I don't think we could drop current hibernate store so easyly. Generic
webdav is the only way for this.
I'm trying to complete first version of JCR Storage before 1.7M1, so we
can test webdav on it.
I think we should keep generic webdav (at least for some time), but it
depends on how hard to support it.
--
Artem Melentyev