-
Notifications
You must be signed in to change notification settings - Fork 103
Should updates about a container only subscribe to direct members, or recursively? #180
Comments
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 |
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 |
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/?The text was updated successfully, but these errors were encountered: