Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV

[Michael Toomim <[e-mail]>]

Bron Gondwana:
> At this point the big difference is whether you want a push of the entire resource, or (as JMAP does) an edge trigger to say "there's something new of this object type on the server - issue a query about which bits you're interested in to see if there's anything new you want to fetch".
> 
> At which point the granularity of detail becomes interesting - because you only want to be informed of changes if there's a high probability that they are things you are interested in, and even more so - if there's a high probability that you'll be able to see them!  You don't want a push every time a resource on a server with a million users changes if you can only see your own resources!
> 
> We do that on our own server with pushing you every change to you own resources plus doing ACL filtering to see if any other user can see the resources and giving them an ACL push too, even if they aren't subscribed to the resources and won't notice a change.... so there could be more smarts in the push filter but it seems to balance out OK in a real life, just the occasional extra wake.  And we separate data types like email and calendar into separate change pools.


Ah, yes the JMAP approach is to inform the client of EVERY change to EVERY object, even if that object isn't being displayed right now. The client just ignores the unnecessary changes.

That works well enough for email, where all changes are bounded to the user's mailbox, and things just don't change that often. However, it doesn't scale to the general case, where a server might be serving millions of resources, and any client could conceivably want to watch any of them, but probably only a few at a time.

It is much more efficient here for a client to explicitly subscribe to the resources it wants to watch. In Braid, you subscribe to a resource by adding the Subscribe header to a GET. Then the server promises to send you updates, even if you go offline, until you explicitly give it a FORGET.

This means that the granularity of subscription is a URI, and clients are responsible for expressing which URIs they want to subscribe to. This works quite well in practice. You usually start out with just a few URIs, which means your client will do a few GETs, and then if you need finer granularity, you can always break up your objects into multiple URIs. The Linked JSON spec <https://raw.githubusercontent.com/braid-work/braid-spec/master/draft-xx-httpbis-linked-json-00.txt> makes that easy.