- Date: 2021-12-15T14:00:00Z
- Call: https://meet.jit.si/solid-specification
- Chat: https://gitter.im/solid/specification
- Repository: https://github.com/solid/specification
- Justin Bingham
- Kjetil Kjernsmo
- Tim Berners-Lee
- Sarven Capadisli
- No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
- Join queue to talk.
- Join the W3C Solid Community Group, W3C Account Request, W3C Community Contributor License Agreement
- Solid Code of Conduct, Positive Work Environment at W3C: Code of Ethics and Professional Conduct
- Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
- If this is your first time, welcome! please introduce yourself.
- Justin Bingham
- name: text
URL: #362
KK: Proposed this alternative to #352
JB: Starting reviewing #362 this morning. ... Generally like the approach - good that it allows for separate permissioning. This same pattern should be applicable to regular (non-container resources) for server-maintained date (e.g. creator). Questioning whether we should structure the section to account for that later in case we shift it around.
KK: 3 good effects - doesn't change the container itself, so last modified is last modified for the whole resource. don't get the cascade effect to root. can permission separately.
TBL: How is the authorization handled / managed?
JB: Current text doesn't explicitly say how to authorize access - and it's listed as an auxiliary resource - so it should be explciit
TBL: What if it was a different type of resource (not aux)? Maybe a regular resource with its own acl?
JB: If it was a regular resource then you'd have these resources interspersed with regular ones which may create a lot of new problems for clients / apps
KK: Motivation for this approach is to ensure that we have a good approach for caching. Tracking changes when you don't have a file based backed is tough to implement.
TBL: Explain the caching issue
KK: Size and MTime can be stale in a conditional request. Would have to have weak etags / validators.
TBL: So we're breaking the semantics of last modified?
KK: No because it is not strict in the RFC but we're stretching it so people's assumption is breaking.
TBL: People assume if last modified hasn't changed than nothing changes at all. So specs should be explicit, and we could be explicit in Solid.
KK: #352 is more explicit about that, but worry about future implications
TBL: Decision point is do we for .9 strictly document what NSS / CSS does so we can. get .9 out. Could say that we understand we're documenting existing practice - that's what .9 is for - and explain the issue with Last Modified and that we'll revisit in the future. Could put a MAY in for now. ... Things that need data could loop with HEAD for now. Can look at #362 approach later. Could also introduce. theconcept of a hidden file.
KK: Depends on community expectation for .9
SC: If server deems resource metadata to be inapplicable they could not do it to begin with
TBL: Hard to say it's not inapplicable - what happens when I do a HEAD on the contained file
SC: Was responding to whether resource metadata is available in the container description to begin with. If they aren't able to produce size, last-modified, etc. Language in the PR doesn't ...
TBL: Argument that it might take to long to load data is questionable. But semantics of last modified data (per Kjetil) is important.
SC: Is an implementation issue to address.
TBL: NSS can't address that - it uses the inode last modified date. If it changes then you get Kjetil's problem. Any change in the entire pod changes last modified up to the pod root.
SC: Current PR clarifies how to determine the last modified
KK: Yes but then some data may be stale. ina conditional request
TBL: Important that if you have somethingh and last modified hasn't changed that you have. thelatest copy. Problem is the last modified data doesn't apply to. thebits in the resource.
SC: It's not required
TBL: It's nice if it does. Propose that we put in 0.9 what NSS does, and a warning that the last modified applies to only the containment triples. NSS goes to the underlying file resource and produces a listing. Last modified is last modified. ofunix directory, which maps to the contained resources.
SC: So if i do a patch on container to add a label, it will not change last modified? (TBL: No)
SC: Slightly strange that last modified for the container doesn't apply to container changes.
TBL: Yes that's what's Kjetil has been saying. So lets describe exactly what NSS / CSS does and roll it down for 0.9, then mark it as a known issue and aim to fix it in subsequent version.
SC: Attention to #352 . Do we want what's there (line 576) or the following (removing "the selected representation"):
JB: current text:
<p id="server-container-last-modified">Servers can determine the value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on modifications to the selected representation or changes to containment triples.</p>JB: proposed adjusted
<p id="server-container-last-modified">Servers can determine the value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on changes to containment triples.</p>KK: Preferred way of doing is to have stat resource. -but want to have .9 out so we could revisit later.
SC: What issue is remaining - aaron's isn't objecting to 352 proposed.
KK: Isn't in good service. ofcaching systems. will lead to stale data.
TBL: Need to put a note somewhere about this problem
SC: What should we include in the note for at risk
TBL: Must remove the selected representation (use proposed adjusted text)
SC: Is the additional note needed for .9?
KK: Helps ESS cope with a question about whether to do it now or not
SC: I don't know that they want to expose last modified in container description to begin with
TBL: Proposed Note:
Note: The last-modified date of a container reflects the basic strucre of the resource tree, but it will but not change when otehr metadat such as the last-modified dates of contained resources, change. This is to avoid the instant propagation of changes all the way top the root of the pod. This means, though, that it cannot be used to check whether the container representation has changed in any way.
At risk: In future versions of this spec, this design may be revisted.
KK: I think it makes it clear to people that there's thought around this. Early discussions with Akamai were related to concern around caching of pod resources.
TBL: How easy to adjust this PR to make these changes?
...PR updated during live meeting...
...Final text reviewed live...
MERGED
URL: #346
KK: Any outstanding issues / concerns?
JB: Already reviewed +1
SC: Reason for change to InsertDeletePatch?
KK: Better / more specific semantics
SC: OK to merge? (.. all agree)
MERGED