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/