8 Oct
2008
8 Oct
'08
6:37 p.m.
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.
Thanks
- Asiri
8 Oct
8 Oct
7:42 p.m.
Hi Asiri,
What do you propose?
Thanks
-Vincent
On Oct 8, 2008, at 6:37 PM, 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.
Thanks
- Asiri
7:58 p.m.
I second Vincent's question,
last I looked at JackRabbit, I couldn't find a convincing WebDAV
interface, so giving details on each approaches would be rather
interesting.
paul
On 08-oct.-08, at 19:42, Vincent Massol wrote:
Hi Asiri,
What do you propose?
Thanks
-Vincent
On Oct 8, 2008, at 6:37 PM, 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.
Thanks
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
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
9 Oct
9 Oct
7:45 a.m.
Hi,
On Thu, Oct 9, 2008 at 12:51 AM, Artem Melentyev <amelentev(a)gmail.com>wrote;wrote:
Asiri Rathnayake wrote:
In addition to these, as pointed by ludovic, the views provided by the
generic-webdav implementation is different from what will be provided by a
standard JCR backed webdav implementation. Our implementation of webdav
interface is documented here :
http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService. I don't think
it'll be possible to provide the same exact interface via the JCR backed
webdav server.
Anyway, i wanted to mention that implementing a JCR backed webdav server is
comparatively easy and there is less maintanance because jackrabbit will be
taking care of most of the server development.
IMHO, we should continue to work on the generic webdav server and once JCR
storage is ready we should implement the JCR backed webdav server separately
(this should be easy AFAIK). Then we can actually have a better
understanding and may be we can provide both implementations (users will
pick what they prefer).
WDYT ?
- Asiri
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Oct
10 Oct
1:47 a.m.
Asiri Rathnayake wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
On Thu, Oct 9, 2008 at 12:51 AM, Artem Melentyev <amelentev(a)gmail.com>wrote;wrote:
+1, our WebDAV server reflects more the XWiki data model and the XWiki
concepts. The JCR DAV view looks more like an mySQLQueryBrowser tool
that lets you browse the database, but doesn't make an application out
of your data (a forced comparison, I know, but it's true).
Even in the future I'd be for using our own WebDAV server than the JCR one.
Asiri Rathnayake wrote:
In addition to these, as pointed by ludovic, the views provided by the
generic-webdav implementation is different from what will be provided by a
standard JCR backed webdav implementation. Our implementation of webdav
interface is documented here :
http://dev.xwiki.org/xwiki/bin/view/Design/WebDAVService. I don't think
it'll be possible to provide the same exact interface via the JCR backed
webdav server.
Anyway, i wanted to mention that implementing a JCR backed webdav server is
comparatively easy and there is less maintanance because jackrabbit will be
taking care of most of the server development.
IMHO, we should continue to work on the generic webdav server and once JCR
storage is ready we should implement the JCR backed webdav server separately
(this should be easy AFAIK). Then we can actually have a better
understanding and may be we can provide both implementations (users will
pick what they prefer).
WDYT ?
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.
11:46 a.m.
Asiri Rathnayake wrote:
<snip>
IMHO, we should continue to work on the generic webdav server and once JCR
storage is ready we should implement the JCR backed webdav server separately
(this should be easy AFAIK). Then we can actually have a better
understanding and may be we can provide both implementations (users will
pick what they prefer).
WDYT ?
+1
--
Artem Melentyev
5874
days inactive
5876
days old
6 comments
5 participants
participants (5)
-
Artem Melentyev -
Asiri Rathnayake -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol