[michielbdejong]

No description provided.

[michielbdejong]

no need to review this now, just documenting that this is something we're experimenting with in https://github.com/inrupt/websockets-pubsub

[michielbdejong]

See also #180

[michielbdejong]

Do not merge unless NSS also implements this.

[RubenVerborgh]

Thanks for clarifying the recursive part, @michielbdejong.

At this point, I want to express my concern regarding the number of notifications that will nee to be generated by the server, and processed by the receiver.

If we want recursive notifications, we might want to make such recursive subscriptions a) explicitly opt-in (so non-recursive is also still possible) and/or b) optional for the server.

[michielbdejong]

Yes, I see your point. But note that notifications will only be sent for resources that the app has read access to.

And even without that change, the number notifications to be sent (number of resources in a single container that the client is subscribed to) might be prohibitive, so this will generally increases the number in practice, but the worst-case number was already huge.

[RubenVerborgh]

But note that notifications will only be sent for resources that the app has read access to.

That doesn't necessarily make it better for the server though, because now every change within a subscribed subfolder should be ran through the ACL process.

the number notifications to be sent (number of resources in a single container that the client is subscribed to) might be prohibitive, so this will generally increases the number in practice, but the worst-case number was already huge.

Yes, but it used to be the case that you needed to do a lot of actions to get a large volume; now a single action can get you a large volume. That works both ways.

This reinforces my belief that we should design an update subscription mechanism instead of extending a quick hack that happened to be built at some point (#179 (comment)).

[RubenVerborgh]

Concerns about scalability, and whether we should not design a proper notification mechanism from scratch. In particular, we should examine whether recursive subscriptions should be explicit and/or optional for the server.

[michielbdejong]

every change within a subscribed subfolder should be ran through the ACL process.

that's already the case right? also if container subscription is not recursive?

design a proper notification mechanism from scratch

Sure, go ahead and propose something! Let me know if you want input. This PR just documents what inrupt/pod-server currently does.