Note that only empty containers can be deleted

[michielbdejong]

I added that note about this in the WAC spec but it actually belongs here in the api-rest document.

The LDP spec seems to leave this out of scope.

This implies a 'no' to the question of should deleting a container also delete all its members and members of members (descendants).

[michielbdejong]

we discussed this in the weekly meeting, and I think we have consensus

[RubenVerborgh]

we discussed this in the weekly meeting, and I think we have consensus

Being? 🙂

[fabiancook]

I feel like the specification should allow this, often times you find yourself needing to be able to do a recursive delete of all information within a container, for example, if a pod provider was deleting out a directory because the agent has a request to be forgotten, and the container is owned by that agent.

Instead of stating a container can't be deleted if it has members, state that an agent without sufficient access to delete all members of a container, therefore cannot delete all members in the container. This would mean an agent could request to delete all members within a container that I have sufficient access to do so. An example of where this would be relevant is where an agent is requesting all information to be deleted, but someone is processing a payment which has been verified beforehand, so the agent can't request to delete their bank account, because there may be an associated payment resource associated with that payment method that owns to the person being paid.

This is a really rough example of where this would be super handy, but I think it warrants consideration as to how this fits into the discussion. One thing we need to be able to support from the specification up is the rights to agents and consider exactly what should be always available to them, no matter who the provider. One of those things I believe is right to move across the network with zero lockins, whether that is the agent just doing a general migration between machines, or if its between providers.

[michielbdejong]

@fabiancook the specification does allow deleting an entire subtree by deleting resources one-by-one, it will just take multiple DELETE requests instead of a single one

[fabiancook]

I'm aware of being able to do multiple deletes, but feels over stepping at the spec level when the only technical limitation seems to be if a member has different access requirements. If the agent can delete all members anyway, they should be allowed to do it in one request.

[michielbdejong]

they should be allowed to do it in one request

OK, then we disagree! :)
So let's go forward as follows:

• we document what node-solid-server, Trellis and inrupt pod-server all implement, namely container delete does not delete subtree, but only deletes the container itself, and only if it's empty (like rmdir)
• we create a separate issue to document your proposal (subtree is also deleted, like rm -rf) as a proposed spec change, following the regular process for proposed spec changes.

would that be ok with you?

[acoburn]

Just be aware that a recursive delete (rm -rf) has some thorny issues when doing this at scale on a distributed platform. At some level, a recursive delete will require/assume some degree of consistency and atomicity (i.e. locking) across the entire operation. Performing this operation over a small container when the server is implemented on a single node over a filesystem is really not much of an issue; when there are millions of sub resources spread across multiple nodes, this becomes extremely difficult.

The other issue is that consistency of behavior is important across implementations. If DELETE operations behave very differently on different implementations of Solid, that will make interoperability much more complicated.

By restricting DELETE operations to empty containers, this does make DELETE operations more onerous on the client if the intent is to remove an entire sub-tree, but it also makes the interaction more explicit.

[fabiancook]

would that be ok with you?

Yep thats perfect. Below are some more details, as well as details for each implementation

---

Recursive delete can be optional, either a delete of that container will return something like 202 Accepted if its a background task, 204 No Content if its already done, or 405 Method Not Allowed if we can't delete on that container, if 405 is returned, fall back to recursive delete from client.

From the LDP spec's point of view the only thing that needs to be done is:

5.2.5.1 When a contained LDPR is deleted, the LDPC server must also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC.
5.2.5.2 When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server must also delete the associated LDP-RS it created.

So the only thing we should be doing is removing the reference for the container, not all its children. I read this as "If my container is deleted, I no longer exist", rather than "Delete members when container is deleted", all the members are orphaned instantly, whether they're actually deleted or not is a clean up task for the service.

If I'm reading what it's saying wrong, then is there some more resources we could reference on this topic?

node-solid-server

node-solid-server currently only deletes a container if it is empty, which is only a logical condition, not technical limitation.

Given this PR, it will also delete the container if its only members are .acl and .meta files: nodeSolidServer/node-solid-server#1180

Trellis

As far as I can tell, all resources are deleted the same https://github.com/trellis-ldp/trellis/blob/a9f4c235dea3919e5c0ff343f466bb9049853267/core/http/src/main/java/org/trellisldp/http/impl/DeleteHandler.java#L149

A BasicContainer is a Resource AFAIK, so deleting a container would delete everything within.

Inrupt pod-server

This implementation (with in memory being the target store) will retrieve all descendents and delete them:

https://github.com/inrupt/wac-ldp/blob/85989783456a6d2211e429c413af5c295037eee0/src/lib/storage/BlobTreeInMem.ts#L52

Open Network

This implementation will delete by way of rimraf: https://github.com/o-network/http-store/blob/master/src/fs-store/methods/delete.ts#L86

[RubenVerborgh]

405 Method Not Allowed if we can't delete on that container

That's not right; 405 means that this method is not supported by the target resource, whereas it is supported but depends on other resources being deleted first.

[fabiancook]

Ah yes, was unsure what should be used for that negative case. What status code would be more relevant?

[RubenVerborgh]

409 Conflict https://tools.ietf.org/html/rfc7231#section-6.5.8