[xwiki-devs] Resolving the mismatch between an xwiki page and a dav collection resource.
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>
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/
Hi Sergiu, On Thu, Nov 27, 2008 at 11:11 AM, Sergiu Dumitriu <[email protected]> wrote:
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?
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Nov 27, 2008 at 11:04 AM, Asiri Rathnayake < [email protected]> 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>
participants (2)
-
Asiri Rathnayake -
Sergiu Dumitriu