This repository was archived by the owner on Apr 13, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 13, 2022. It is now read-only.
When deleting a resource, should the corresponding ACL document also be deleted? #187
Description
In other words, would nodeSolidServer/node-solid-server#1180 be a violation of the spec?
Activity
michielbdejong commentedon Jun 5, 2019
This is a complicated topic, related to #172.
A cleaner solution would, I think, be to say ACL documents should just show up in container member listings?
michielbdejong commentedon Jun 6, 2019
@jaxoncreed what do you think of the solution where acl docs show up as container members so that it's not such a pain to guess their paths when trying to delete a container (in other words, give the app the ability to see whether a container is empty or not, and if not, which members still exist)
jaxoncreed commentedon Jun 10, 2019
@michielbdejong I personally don't like it. I think that .acl files are essentially metadata and not documents themselves. I can see how this becomes easier for certain operations like delete, but other operations would require you to differentiate between acl files and regular ones for access control. Plus, I think it would be confusing on the user's end.
RubenVerborgh commentedon Jun 10, 2019
The spec does not support that interpretation though. Quite the contrary: ACL files are RDF documents, that can contain arbitrary triples. The only differences are that a) some of those triples will determine access control to other documents and b) viewing or editing them requires Control permissions instead of Read or Write.
jeff-zucker commentedon Jun 10, 2019
How about the equivalent of ls -al? In other words .acl and .meta are invisible to a regular GET on a container but visible with a special GET?
Or on a different track : always delete all .acl and .meta when deleting an otherwise empty container. This would prevent the current possibility of undeletable containers filled with undiscoverable .acl files.
humont commentedon Aug 17, 2019
For what it's worth, in my current implementation I treat a DELETE request to a container as acceptable if the container if all it contains are it's own .acl and .meta file - I did pause to reflect at the time of implementing, but it struck me as an intuitive way of going forward.
Given that .acl and .meta files are not files with which a user will routinely interact, requiring the user to delete them (or throwing an error when the user attempts to delete a container which stll contains them) seems like it would produce additional friction to the UX in a way that is not immediatley transparent.
In line with this, I am currently parsing a DELETE request for a resource by fetching any "describedBy" and "constrainedBy" files that concern only it (quite easily verifiable by traversing the graph contained within these files).
dmitrizagidulin commentedon Sep 24, 2019
Semi-duplicate of solid/solid#251
Will be tackled in solid/specification#58, closing this one.