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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
