Repository navigation
proposal: deleting a container is a noop #173
Description
Activity
My reading of the spec is that creating a container (via POST) is manual. That creating a container on its own with PUT is not allowed. That a container may be created as a by-product of creating resources in it. So deleting a container is symmetric with creating one with POST and should be manual. There are also use cases in which one wants to delete all the resources in a container but not delete the container.
There are also use cases in which one wants to delete all the resources in a container but not delete the container.
Which use cases are these?
Re-Initializing a folder tree for an app. But because of the way PUT operates, deleting it or not deleting it is pretty much the same so nevermind.
Reacted by Fabian CookAnd what about creating/foo/bar/baz.ttl. When we delete we might want to delete baz.ttl And /foo/bar without wanting to delete /foo But if it's symmetric with the create it would be.
Ah, here's a use case: I create /foo/jamal/ to hold messages from Jamal and I create a .acl file to give Jamal write access to that folder. Just because I delete the last message from Jamal doesn't mean I want to delete the folder and its .acl.
a container with a .acl document in there is not an empty container.
I mainly proposed this to track it as an option, I think the current behaviour is fine as it is, and don't think it's worth a spec change.
The spec already says that creating a container is automatic (
mkdir -p).So if you create and then delete
/foo/bar.ttl, it seems asymmetric that you then do have to delete the/foo/container afterwards if you no longer want to seefooas a member listed in/.This would also resolve confusion around how exactly container deletes should work (should sub-trees also be deleted, should they fail if the container is non-empty, what should happen if you deleted a resource but not its ACL, how can you know if any ACL docs exists, if they are not listed as members, etc.)