-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify container notifications for websockets-pubsub #233
Comments
Thanks for raising this! Will incorporate this in the Protocol specification. I offer an explanation that is closer to your third interpretation but with some differences. It is based on what's currently in the Protocol specification and also aligned with security considerations eg. #228 : As per reading resources, a WebSocket subscription to a container requires read access privilege on the container in order to observe changes to container's state. Observable changes generally include changes to the containment statements ie. when adding or removing resources. Updates to the container (as with any resource) are also state changes eg. when adding a label, and so triggers a notification to subscribers. Aside: at this time, the Protocol specification doesn't require that container representation includes anything beyond containment statements. See also: #227 As per PR 228: When a server creates a resource on HTTP PATCH, the container representation of the created resource will be effected as per containment rules. Hence, a notification is triggered. |
Thanks! I agree that is the interpretation that makes the most sense. It is also what the test suite expects (hence the failing tests for CSS). |
@timbl can you take a decision on this? |
@RubenVerborgh Just to clarify, are you saying that current CSS behavior leaks less information? |
Can you give an example where resource |
Sure but subscribing to resource changes via websockets-pubsub is already a read operation by definition. That's already true even if you emit only on If CSS doesn't emit for containers, then how can you know if a new post came into your inbox? Or do you make an exception for POST? If so, then how can you find out if a new resource was added to a container using a verb other than POST? Another downside of your interpretation is scalability, I think. If a container has 1,000 resources that rarely change then the client would need to send 1,000 The main downside of your proposal is, I think, that it treats containment triple changes as somehow less real than other changes in non-container RDF sources. It raises all sorts of questions: do you also not emit if a container is changed with POST? Do you also not emit if other triples the container may have (e.g. folder title) are changed? What makes containment triples so special that we shouldn't emit a |
Ah great, so then we all agree that adding or removing a containment triple does count as a change for which
Great! "not yet" is fine, should be easy to fix. See https://github.com/solid/community-server/issues/612 and @joachimvh's comment there.
Good point about unconditionally emitting on PATCH, I'll add a test for that in solid-crud-tests. |
I can think of three ways to interpret the text "all CRUD operations (POST, PUT, PATCH, DELETE) performed on resources of that container will trigger a notification for the container URI" in https://github.com/solid/solid-spec/blob/master/api-websockets.md#subscription:
DELETE
and notPATCH
is at least consistent with it. So this is basically: only publish on the container if that container's containment triples changed. Which in itself is quite neat and simple, I think.PS: I think we agree that "resources of that container" means only resources that are directly contained in it (so equivalent of
ls
on unix), so not resources that are contained in subcontainers (what would be the equivalent of a recursivels -R
on unix). But let's add a test in solid-crud-tests to be sure that servers don't notify for all ancestor containers up to the root.The text was updated successfully, but these errors were encountered: