You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
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.
Should updates about a container only subscribe to direct members, or recursively? #180
I added 'Clarify that updates about a container only subscribe to direct members, not recursively (we could really go either way I think, but we should pick one)' to #179 but then realized that this is actually a separate clarification which we need to decide about. I can see arguments for both options.
Well, if "too many subscriptions" would be a reason to close the connection, then the recursive option would be preferable; it would allow me to filter a single subscription client-side when I do not need deep members, rather than having to set up many subscriptions when I do.
Ideally, the common case would be the option we pick, but given that there aren't that many apps building on Solid yet, I find it hard to predict what that would be.
Good point. I should also specify that if an app send sub https://example.com/ it will not receive notifications about each change on that storage server; only about the ones it has access to.
Minor point: I wouldn't use the phrase "direct members" to mean "contained resources" because it creates some ambiguity around LDP membership resources, especially w/r/t direct containers. OTOH, I realize that "contained resources" might be too broad, since it could imply the resources of an entire sub-tree (containers of containers). We just want to be precise about the language.
We need to think more about implementation consequences for clients and servers, in the context of scalability as well. Would postpone decision until we have more data.
Activity
Vinnl commentedon May 29, 2019
Well, if "too many subscriptions" would be a reason to close the connection, then the recursive option would be preferable; it would allow me to filter a single subscription client-side when I do not need deep members, rather than having to set up many subscriptions when I do.
Ideally, the common case would be the option we pick, but given that there aren't that many apps building on Solid yet, I find it hard to predict what that would be.
michielbdejong commentedon May 29, 2019
Good point. I should also specify that if an app send
sub https://example.com/it will not receive notifications about each change on that storage server; only about the ones it has access to.acoburn commentedon May 29, 2019
Minor point: I wouldn't use the phrase "direct members" to mean "contained resources" because it creates some ambiguity around LDP membership resources, especially w/r/t direct containers. OTOH, I realize that "contained resources" might be too broad, since it could imply the resources of an entire sub-tree (containers of containers). We just want to be precise about the language.
RubenVerborgh commentedon Jun 13, 2019
We need to think more about implementation consequences for clients and servers, in the context of scalability as well. Would postpone decision until we have more data.
scenaristeur commentedon May 14, 2020
As app developer it would be cool if I could choose with a subscription option if I want recursive or not