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

[Michael Toomim <[e-mail]>]

Ranjit:
> why can't we use WebSockets which is based on HTTP and helps keep session active? 

Thank you for the question. We certainly could use a WebSocket, and in fact, the previous version of the spec <https://tools.ietf.org/html/draft-toomim-braid-00> did use a WebSocket as transport! The question is why you'd prefer to use a WebSocket as the underlying transport, rather than a multipart-body GET request. Since we still want all the great things from HTTP— caching, URLs, idempotency, content-types, etc. —we'd either have to implement all the existing HTTP methods on top of a WebSocket, or add these new subscription features on top of HTTP. In the end, it seems to be simpler and more elegant to do the latter.

Also, the introduction mentions WebSockets—did it address your question adequately? Or is there something we should add to this:

1.  Introduction

  When a client GETs a resource over HTTP, the server provides the
  latest version, but does *not* provide updates when the resource
  changes.  This means that programmers have to implement workarounds
  whenever they need to synchronize with data that changes.

  The web originally required users to click reload when a page changed.
  In the year 2000, XMLHTTPRequest made it possible to update just part
  of a page, running a GET request behind the scenes.  But the GET
  request still could not push updates.  To work around this, web
  programmers would poll the resource, which was inefficient.
  Long-polling was invented to overcome the inefficiencies, which was
  standardized as SSE.  But SSE provides semantics of an *event-stream*,
  and although a programmer can encode a protocol within the event
  stream for updating a resource, there is still no standard way to
  update a resource.  In practice, programmers today often give up on
  using a standard semantic for "data that changes", and instead write
  their own idiosyncratic update protocol over a WebSocket, or adopt a
  web framework that does this for them.

  However, we can add support for "state that changes" into HTTP with a
  few small extensions.  Doing so transforms HTTP from a *state
  transfer* protocol into a *state synchronization* protocol, and
  extends the REST architecture into RESS: REpresentational State
  Synchronization.
https://raw.githubusercontent.com/braid-work/braid-spec/master/draft-xx-httpbis-braid-00.txt <https://raw.githubusercontent.com/braid-work/braid-spec/master/draft-xx-httpbis-braid-00.txt>
But let me say that some things actually are more elegant to implement with a WebSocket. Specifically, we are finding the request/response model of HTTP to be getting in the way. After this spec is complete, I expect us to propose a generalization of request/response that can run peer-to-peer over a QUIC channel, in which either peer can initiate or respond to GET and PUT requests, and both peers will ACK changes in state symmetrically. We sketched this in Section 4.2 of the the previous spec <https://tools.ietf.org/html/draft-toomim-braid-00#section-4.2>. It makes the protocol both simpler and more capable.

Thank you, Ranjit!