Container questions

[communitysolidserver]

Container questions

[csarven]

LDP (5.2.3.4) doesn't specify what servers should do if client doesn't request an interaction model. So, implementations may reject or derive an interaction model by other means. As Aaron mentioned, the interaction model is unnecessary for Solid because the shared semantics of slashes in URI path and so "[p]aths ending with a slash denote a container resource."

Solid servers do not observe client's requested Link header about the "interaction model" with one exception ( solid/specification@c1aac42#diff-a9469ae9dd70007b20d4207586e2855aR145-R151 ) ie. when creating a container:

Servers MUST allow creating new resources with a POST request to URI path
ending /. Servers MUST create a resource with URI path ending /{id} in
container /. Servers MUST create a container with URI path ending /{id}/
in container / for requests including the HTTP Link header with
rel="type" targeting a valid LDP container type. Servers MUST handle
subsequent requests to the newly created container's URI as if it is a valid
LDP container type by including the HTTP response's Link header.
[Source]

with the intention of:

Clients who want the server to assign a URI of a resource, MUST use the POST request.

Aside: I think we can actually safely drop the server requirement for servers to include the Link header in response. The only reason that I can recall on why we kept it (for the time being?) was to have some alignment with LDP. I don't think that compatibility is significant however ie. helping only LDP-aware clients understand the interaction model of the resource made available from a Solid server.

It is impossible to have orphaned resources in Solid, so, can't delete a container without deleting its containments first. Recursive delete is put on ice as there is no consensus on how to do it.

[RubenVerborgh]

A container should contain triples referencing its children. These need to be updated after deleting a child resource. Should this be the responsability of the resource store or is this another place to have a specific store with a decorator pattern?

The store should do this, as the behavior is different per store.

For a file system, those triples can be generated at runtime via ls. A triple store might materialize them.
We might want some reusable helper object that can do such materialization, but I would recommend to do this via composition rather than inheritance. (Then the file system module could also use it, but at read time rather than at write time, how cool is that.)

Related to the previous: whoever is responsible for this needs to have a way to find the parent of a resource, I'm thinking this might be a separate class/function entirely, since the Acl handler is also going to need this?

Agreed.

A file based resource store can sort of break from the above by simply checking which files are present in a folder to generate the membership triples (although the parent function is still needed for acl then). But where is the other data besides the membership data stored of the container in such case?

A meta file, I think.

If I understand the LDP spec correctly here, a client has to add a Link header describing the type when doing the POST, thereby identifying if they're adding a resource or creating a new resource. Does this mean we should reject all POST requests without that header?

@csarven, what is the consensus on this?

What do we want to do when deleting a container? It's not required to delete the children but it could cause a bunch of invisible resources.

Also need @csarven on that one 🙂

[acoburn]

If I understand the LDP spec correctly here, a client has to add a Link header describing the type when doing the POST, thereby identifying if they're adding a resource or creating a new resource. Does this mean we should reject all POST requests without that header?

Having implemented an LDP server, I find the requirement for a link header (identifying the interaction model) to be too strict -- it impedes adoption and it's usually unnecessary anyway (if I'm POSTing a text/plain payload, why do I also need to say it's an LDP-NR?).

But while it is always completely clear when a client is explicit with a link header, what are the heuristics for the server to decide on the interaction model when a client doesn't provide one. Having shared heuristics is important here, and there is an extensive discussion here: solid/specification#128

Re: delete, the idea is to allow delete on non-empty containers. If a container has child resources, a DELETE operation would return a 409 Conflict response. The related text is in this PR: https://github.com/solid/specification/pull/188/files#diff-a9469ae9dd70007b20d4207586e2855aR224