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/