Subscription without payload about braid-spec HOT 6 CLOSED

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?

from braid-spec.

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.

from braid-spec.

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?

from braid-spec.

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!

from braid-spec.

Closing this issue; discussion of subscription parameters is moving to #123.

from braid-spec.

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.

from braid-spec.