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:
- 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).
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: