Subscription without payload

[mitar]

I have been recently experimenting with some state syncing for one web app I am developing and I have came up with the API organized as:

• An endpoint to get various versions of the resource and patches/diffs between versions.
• A subscription for changes of the resource where I get over subscription just information that the resource has changed from version to version.

This allows the app to control the rate of updates to its state and UI. It can also control the amount of data it is getting from the server. It gets notifications about new versions but it can decide when to then do another request to fetch the data/new state (or the whole resource at version X or a diff between the version it has and the new version, the app decides).

The downside is of course extra requests made from the client to the server and latency introduced by that. But in my experience this is OK trade-off, you rarely need the lowest possible latency, but you can on the other hand batch many changes in a row into one request (e.g., you get 10 notifications for changes in one second, and then you can ask for a diff from the version you have and the latest of those new versions).

So I wonder if braid could support that? Maybe by requesting an "empty patch" patch type?

[toomim]

If I'm hearing you correctly, the key distinction here is that the notification feed tells you something changed, but doesn't describe the change.

This is, indeed, a common pattern, and I love being challenged to make Braid support all the unique patterns we can find.

However, it would really help to ground this work in a use-case with a clear benefit to not send the change description inside the notification itself. The only advantage I can think of is to save network bandwidth, in the case that the client doesn't actually want to download the change. But is there a use-case to be notified that there is a change, and not actually want to update state to it?

I'm failing to think of one. Do you have any ideas?

I can imagine it might be easier conceptually to design this system, as a programmer, because the notifications syntax will be simpler. But we've already designed a general notification-with-change syntax, and having that, I don't see why I'd switch to a change-free notifier. What do you think?

[toomim]

IIRC, this is also the architecture currently used in Solid, btw. Tim Berners-Lee told me as much at dweb, this summer, and said that he'd like them to switch to something better.

I don't fully understand if this is the right link, yet, but this might be what Solid is currently using: https://docs.inrupt.com/developer-tools/javascript/client-libraries/reference/solid-client-notifications/

Rahul Gupta (user @CxRes) has been working on an improvement, which he just submitted to IETF Dispatch called PREP.

[mitar]

The only advantage I can think of is to save network bandwidth, in the case that the client doesn't actually want to download the change. But is there a use-case to be notified that there is a change, and not actually want to update state to it?

So to me it is not about network bandwidth itself, but also about client being in the control on when and how to update (maybe it does not need to sync state in real-time, maybe every 5 minutes is good enough, maybe it does not have to do patches but can just fetch a snapshot every 5 minute). Updating state in browsers for example also generally forces re-render of DOM (if you connect all state propagation). Sometimes this is what you want. But not necessary always. Or at least you want to control how often (e.g., user moves the tab into the background, you should be able to slow down/pause syncing, but still be ready to fetch & rerender when they switch back, if it is necessary).

and said that he'd like them to switch to something better.

Do you know in which way "better"? What are shortcomings for them?

[toomim]

Excellent, that provides much more clarity. Thank you!

These are cases where the client wants to have control over the subscription:

• rate of updates
• format of updates (snapshot vs. patches)

This is a set of features that are planned for development in version 04+. We actually just talked about them yesterday in https://braid.org/meeting-67 under "Parameters for subscriptions". We will be consolidating them into a single Github issue soon, and when we do, you should weigh in on that issue to make sure that your desired use-cases are addressed within the design!

[toomim]

Closing this issue; discussion of subscription parameters is moving to https://github.com/braid-org/braid-spec/issues/123.

[toomim]

Do you know in which way "better"? What are shortcomings for them?

I remember him saying he wants to be able to support full fancy OT/CRDT. I don't remember specific other concerns, but I remember the latency of an additional round trip being in the air, and perhaps also the complexity of using multiple protocols. There's a websocket that just sends "something has chanaged" messages, and then a HTTP request to get the change. I think it's one websocket for all resources, but each results has its own patch system at its own URL.