@csarven the key phrase is “trying to change the containment triples”. A client may very well not be “trying to change” these triples. It may be that between a GET and a PUT the containment triples have changed because of the actions of some other agent.
The issue largely boils down to architecture — if you have a distributed storage layer and if you want to be strict about this, you kind of have to lock your entire cluster, which results in a huge performance penalty.
Alternatively, the server can ignore containment triples and there is no need for locking.
If a client explicitly wants to avoid the “lost update problem”, that’s what ETags are for
Link: <doc.meta>; rel=metaresource.
@acoburn The request semantics of PUT is simply that client intents to replace the resource state. What may happen before their PUT (eg. change of containment information from their last GET) is orthogonal. I used "trying" informally in chat for "requesting", but let's stick to the language in the current spec for now -- am open to paraphrasing.
Re your example requests in https://gitter.im/solid/specification?at=600ae96c36db01248a95544b , servers must reject the PUT request because it is an attempt to modify/update the containment triple set. 409. If server were to allow changes to the containment (with direct update to the container) the resource state would end up either having a) orphaned resources (by removal of containment statements), b) reference to non-existent resource (by adding containment statements, or both. a) conflicts with another requirement, and also unclear (unspecified) whether those dangling resource are completely unmanageable (re lifecycle) from here on end, b) although seems harmless, it creates additional burden on server eg. needs to respond to these non-existent resources (and possibly their non-existing auxiliary resources).
My understanding of the prior discussions (especially in the PR) was based on the above - happy to rephrase if choice of words can be better. What I'd like to know right now for starters is 1) if we have the same interpretation of the current spec text, and 2) whether there is a request to change the current requirement in light of implementation experience or better understanding of the matter.
If we need to clarify between the updates: 1) modifying existing containment statements 2) adding new containment statements or removing containment statements, I'm open to that as well. The text "update a container’s containment triples" intended to cover both cases ie. the change to the set of containment statements.
@csarven my position is that a resource’s state consists of two things: server-managed data and client-managed data. A client can manipulate all of the client-managed data (with some restrictions) and none of the server managed data.
For the most part, server-managed data becomes part of HTTP headers while client-managed data is RDF. The challege with containment triples is that they appear in the body of the RDF so they look like client-managed triples.
If we dealt with quads, it would be more obvious that the data were partitioned, but it’s ambiguous with triples.
What I think we both agree on is this: a client MUST NOT be able to change a target container’s containment triples via PUT. The difference is really about whether attempting to do so results in a 4xx or just ignoring that part.
I would argue that both patterns should be possible. Requiring a 4xx response is basically a non-starter for implementations with a distributed storage layer because you’d need to lock on the entire container on every write. In the worst case, you’d need to lock the entire server on every write.
@acoburn "Ignoring" may not be accurate, especially if 200 or 204 are used for the response. That tells the client that the representation it provided is now the latest resource state - which would include the requested changes. I can see that "ignoring" could work if the response status was along the lines of a 202 so that there is an out of band step that can make sure the integrity of the resource state is maintained - I'm not saying this is a good idea or making it a proposal.. just want to illustrate but perhaps something of a consideration for implementations that need to lock the container state.
Another approach is that if servers allow PUT to update containers then they are willing to handle potential conflicts. If servers don't want to get into that, they can simply omit PUT on containers.
"Ignoring" may require a 200 with payload as response because server may need (or want?) to indicate the state as the result. Perhaps in addition to ETag.
@/all To get the most out of spec/panel meetings, I propose to prioritise meeting agenda items along these lines:
This is not a strict order and there is no strict time allocation for each. The group should make reasonable effort to touch all items with sufficient time, make sure to mark unfinished discussions to be taken up in future meetings..
If there is something else that should be covered or handled differently, please say so. We can update when there are significant changes to the way meetings are held.
<https://frederick.trinpod.us/@> solid:account <https://frederick.trinpod.us/> ; solid:oidcIssuer "https://trinpod.us"^^<xsd:string> ; solid:privateTypeIndex frederick:t_72 ; solid:publicTypeIndex frederick:t_6x ; space:preferencesFile frederick:t_8d ; space:storage <https://frederick.trinpod.us/> ...
as for protecting the resources in those locations, that would be entirely an implementation decision. One could also argue that users should be in control of their own data, and if they want to delete a container called /inbox/, they should be able to do that
agree - this isn’t something for the core protocol to determine, but a matter of user choice.
@/all What does everyone think about only using quoted access modes for the
WAC-Allow header? The current ABNF for WAC-Allow makes the quotes optional eg.
user=read are both valid. This was intentional. However, as brought up by @edwardsph in testing, if we take the ABNF as is, a parser that's following the ABNF as gospel could potentially generate unmatching quotes, and so it is not fun for clients to bother with something like
user="read public="" . This would be silly and in most situations it would probably be considered a bug by implementations.. but it might be better to tighten this up... so to simplify client's parsing.
Aside: when I originally wrote the ABNF, I followed Content-Type's lead ie. allowing both quoted and unquoted values. However, those don't say anything about unmatching cases.. or factored in.
ABNF is supposed to be "aspirational".. so, we have a couple of choices. We can do one of the following (relatively complex to simple order):
I think 2 or 3 will be fine. Slight preference for 2. 1 is overkill... and may still need some handholding with supporting text.
WOW, I guess I don't remember anything... since we already had this text:
The quoted and unquoted values for <code>access-modes</code> are equivalent. Servers are recommended to use quoted values in the response. Clients' are recommended to be able to parse both quoted and unquoted values.
Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and
Are there any reference in solid spec to the lifecycle management. Is it within the containement triples with dates or etags .... Is there a W3 spec ? NSS use dates.
@bourgeoa In that context, "lifecycle" is as described in https://www.w3.org/TR/ldp/#dfn-containment . Happy to clarify this in the Protocol spec though. The intention is that a container gets to be aware of what happens to its resources eg. deleting a resource also entails that there is a cleanup task in which the containment statement is removed from the delete resource's container. There is also related requirements like disallowing a request to delete a non-empty container.
I'm curious to know what hinted at dates/etags for you though..
@csarven there where 2 questions : the first one came from solidos meeting where @timbl stated that in containement triples there should be date creation and date modified. I did not find any reference in solid spec. And the second was around the discussion in app-development chat around how to know that a resource has changed and where the first response was to check the body content.
If I may suggest that the solid specification give not only a global reference link but also to a paragraph link to the w3 specification.
Suggestion noted, thanks. I'm aware of the date info consideration about container resources in the container description.. will come back to this. (It is currently not a requirement).
For resource changes, yes, well, if authorized, and if present, Last-Modified or ETags are good indicators on each resource. To detect those changes from the container, yes, resource description (but again, if it is available.. and right now it is not required).