[xwiki-devs] Resolving the mismatch between an xwiki page and a dav collection resource.
27 Nov
2008
27 Nov
'08
6:34 a.m.
Hello Devs,
In webdav view of xwiki, a wiki page (document) is represented by a webdav
collection resource (somewhat like a directory). This collection resource is
comprised of wiki.txt, wiki.xml, attachments & child pages. As you can see,
there is a mismatch between these two concepts: without wiki.txt & wiki.xml
(children), a wiki page (the parent) cannot exist, but this is the otherway
around in a filesystem like structure.
So a question arises, in webdav space what does it mean to delete a wiki
page ?
1. We can treat deleting wiki.txt and/or wiki.xml as deleting the whole
page. But deleting the parent when only the children were asked to be
deleted is wrong. And most of the webdav clients go insane.
2. We can prohibit wiki.txt & wiki.xml being deleted (i.e. throw an
exception). But this would prohibit users from deleting pages on some
clients because they use a recursive delete procedure (i.e. delete children
first and then delete the parent). When deleting children fails, the whole
operation fails.
3. We can trick the clients to believe that the delete was a success
(repport AOK) and continue like nothing went wrong. This way a recursive
delete will succeed. But if the client re-request the resource just to make
sure the delete was a success, the deleted wiki.xml and wiki.txt will appear
again. Some clients indeed behave like this and they fail. This is the
current approach we have taken.
4. We can put wiki.txt & wiki.xml inside the HttpSession object the first
time we initialize a particular resource. This way, the deletes will succeed
and even if the client re-validates the delete, those child resources will
not appear again. This approach seems to prevent all of the above mentioned
problems but again, we're using a hack. Also, this implies that a page (dav
collection) can exist without wiki.txt & wiki.xml.
I voting in favour of the 4th option. Do you see any other way to get around
this mismatch ?
Thanks.
- Asiri
[image: Asiri Rathnayake's Facebook
profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>
27 Nov
27 Nov
6:41 a.m.
Asiri Rathnayake wrote:
Hello Devs,
In webdav view of xwiki, a wiki page (document) is represented by a webdav
collection resource (somewhat like a directory). This collection resource is
comprised of wiki.txt, wiki.xml, attachments & child pages. As you can see,
there is a mismatch between these two concepts: without wiki.txt & wiki.xml
(children), a wiki page (the parent) cannot exist, but this is the otherway
around in a filesystem like structure.
So a question arises, in webdav space what does it mean to delete a wiki
page ?
1. We can treat deleting wiki.txt and/or wiki.xml as deleting the whole
page. But deleting the parent when only the children were asked to be
deleted is wrong. And most of the webdav clients go insane.
2. We can prohibit wiki.txt & wiki.xml being deleted (i.e. throw an
exception). But this would prohibit users from deleting pages on some
clients because they use a recursive delete procedure (i.e. delete children
first and then delete the parent). When deleting children fails, the whole
operation fails.
3. We can trick the clients to believe that the delete was a success
(repport AOK) and continue like nothing went wrong. This way a recursive
delete will succeed. But if the client re-request the resource just to make
sure the delete was a success, the deleted wiki.xml and wiki.txt will appear
again. Some clients indeed behave like this and they fail. This is the
current approach we have taken.
4. We can put wiki.txt & wiki.xml inside the HttpSession object the first
time we initialize a particular resource. This way, the deletes will succeed
and even if the client re-validates the delete, those child resources will
not appear again. This approach seems to prevent all of the above mentioned
problems but again, we're using a hack. Also, this implies that a page (dav
collection) can exist without wiki.txt & wiki.xml.
I voting in favour of the 4th option. Do you see any other way to get around
this mismatch ?
I don't like either option. Are you sure there isn't any other way? Some
WebDAV properties?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6:58 a.m.
New subject: [xwiki-devs] Resolving the mismatch between an xwiki page and a dav collection resource.
Hi Sergiu,
On Thu, Nov 27, 2008 at 11:11 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Asiri Rathnayake wrote:
These are the available dav properties :
http://www.webdav.org/specs/rfc2518.html#dav.properties
None seem to be helpful in this situation :(
Thanks.
- Asiri
Hello Devs,
In webdav view of xwiki, a wiki page (document) is represented by a
webdav
collection resource (somewhat like a directory).
This collection resource
is
comprised of wiki.txt, wiki.xml, attachments
& child pages. As you can
see,
there is a mismatch between these two concepts:
without wiki.txt &
wiki.xml
(children), a wiki page (the parent) cannot
exist, but this is the
otherway
around in a filesystem like structure.
So a question arises, in webdav space what does it mean to delete a wiki
page ?
1. We can treat deleting wiki.txt and/or wiki.xml as deleting the whole
page. But deleting the parent when only the children were asked to be
deleted is wrong. And most of the webdav clients go insane.
2. We can prohibit wiki.txt & wiki.xml being deleted (i.e. throw an
exception). But this would prohibit users from deleting pages on some
clients because they use a recursive delete procedure (i.e. delete
children
first and then delete the parent). When deleting
children fails, the
whole
operation fails.
3. We can trick the clients to believe that the delete was a success
(repport AOK) and continue like nothing went wrong. This way a recursive
delete will succeed. But if the client re-request the resource just to
make
sure the delete was a success, the deleted
wiki.xml and wiki.txt will
appear
again. Some clients indeed behave like this and
they fail. This is the
current approach we have taken.
4. We can put wiki.txt & wiki.xml inside the HttpSession object the first
time we initialize a particular resource. This way, the deletes will
succeed
and even if the client re-validates the delete,
those child resources
will
not appear again. This approach seems to prevent
all of the above
mentioned
problems but again, we're using a hack. Also,
this implies that a page
(dav
collection) can exist without wiki.txt &
wiki.xml.
I voting in favour of the 4th option. Do you see any other way to get
around
this mismatch ?
I don't like either option. Are you sure there isn't any other way? Some
WebDAV properties?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:41 p.m.
New subject: [xwiki-devs] Resolving the mismatch between an xwiki page and a dav collection resource.
On Thu, Nov 27, 2008 at 11:04 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
Hello Devs,
In webdav view of xwiki, a wiki page (document) is represented by a webdav
collection resource (somewhat like a directory). This collection resource is
comprised of wiki.txt, wiki.xml, attachments & child pages. As you can see,
there is a mismatch between these two concepts: without wiki.txt & wiki.xml
(children), a wiki page (the parent) cannot exist, but this is the otherway
around in a filesystem like structure.
So a question arises, in webdav space what does it mean to delete a wiki
page ?
1. We can treat deleting wiki.txt and/or wiki.xml as deleting the whole
page. But deleting the parent when only the children were asked to be
deleted is wrong. And most of the webdav clients go insane.
2. We can prohibit wiki.txt & wiki.xml being deleted (i.e. throw an
exception). But this would prohibit users from deleting pages on some
clients because they use a recursive delete procedure (i.e. delete children
first and then delete the parent). When deleting children fails, the whole
operation fails.
3. We can trick the clients to believe that the delete was a success
(repport AOK) and continue like nothing went wrong. This way a recursive
delete will succeed. But if the client re-request the resource just to make
sure the delete was a success, the deleted wiki.xml and wiki.txt will appear
again. Some clients indeed behave like this and they fail. This is the
current approach we have taken.
4. We can put wiki.txt & wiki.xml inside the HttpSession object the first
time we initialize a particular resource. This way, the deletes will succeed
and even if the client re-validates the delete, those child resources will
not appear again. This approach seems to prevent all of the above mentioned
problems but again, we're using a hack. Also, this implies that a page (dav
collection) can exist without wiki.txt & wiki.xml.
I voting in favour of the 4th option. Do you see any other way to get
around this mismatch ?
As I have mentioned in one of my previous emails, the root cause of this is
that we're trying to map xwiki artifacts (attachments, pages, spaces and
virtual groupings of those) into a file hierarchy like structure (webdav)
which doesn't map really well. So, the solution suggested by 4th option is
that we we keep the xwiki->file_hierarchy mapping inside the user's session
object rather than hard coding it. This way, since the hierarchy is in
user's session object, he can manipulate it as he wish (not entirely) and we
can manage the underlying documents (in a most sensible manner) without
failing various clients.
For an example, the same situation occurs with spaces and pages, because a
space cannot exist with zero pages. Same goes with virtual groupings. In the
original scenario, by putting wiki.txt & wiki.xml inside the HttpSession
object we can allow users to edit those files without an issue (here editing
wiki.txt maps to editing the wiki page in xwiki world). But deleting any of
those files doesn't have to mean anything in xwiki world neccessarily
because they are just an abstraction in webdav world. So, inorder to be
compatible with webdav world, we use a hack (4th option).
I'm not sure if i explained myself well. Anyway, if you have any comments
please let me know.
Thanks.
- Asiri
Thanks.
- Asiri
[image: Asiri Rathnayake's Facebook
profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>
5772
days inactive
5772
days old
3 comments
2 participants
participants (2)
-
Asiri Rathnayake -
Sergiu Dumitriu