solid-spec
solid-spec copied to clipboard
Should updates about a container only subscribe to direct members, or recursively?
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.
So when https://example.com/a/b/c/d/e.ttl is updated, all clients subscribed to https://example.com/a/b/c/d/e.ttl or to https://example.com/a/b/c/d/ should get a pub
message. But what about clients subscribed to https://example.com/a/b/c/, https://example.com/a/b/, https://example.com/a/ or https://example.com/?
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.
As app developer it would be cool if I could choose with a subscription option if I want recursive or not