Hacker News new | ask | show | jobs
by brongondwana 4518 days ago
We're using eventsource push - just to say "you need to poll for changes now". I think that's cleaner than trying to push the actual changes.

Our actual push does include some extra detail, but the important bit is just "here's a new state that exists on the server - if you haven't already heard of it, you probably should poll for changes now".

It's out of band(ish) - because JMAP is connectionless. And because depending on which platform you're using, there might be a nice channel for push notifications already.
1 comments
jkarneges 4518 days ago
How about documenting the EventSource interactions?
link
nmjenkins 4518 days ago
We probably will publish this as well. We're focussing on the core API first. Having said that, it's really very simple. Here's the entirety of our (currently internal) spec for push events at FM:

This is a text/event-stream resource, as described in [http://www.w3.org/TR/eventsource/](). The following events are pushed:

- progress: Sent during a long-running api method call to let the client know not to timeout the connection. The data is a JSON object with a single property: `connectionId`, with the id the client sent for that connection. This event does not set a new id in the event source stream.

- push: Sent whenever the user's highest modseq changes. The event id is the new highest modseq. The data for the event is a JSON object, with the following properties:

  * **clientId**: `String` (optional). If the change was due to an action initiated by
    the API, the `X-ME-ClientId` header will be echoed back as this property. This
    allows clients to ignore push events for changes they themselves have made.

  * **mailModSeq**: `Number` (The highest modseq for a mailbox)

  * **contactsModSeq**: `Number` (The highest modseq for contacts/contact groups)

  * **calendarModSeq**: `Number` (The highest modseq for calendar events).
link