Confirmed users
1,018
edits
CloudServices/SimplePushServer: Difference between revisions
→Overview
| Line 25: | Line 25: | ||
==API Reference/Documentation== | ==API Reference/Documentation== | ||
=== Overview === | === Overview === | ||
* APP requests an ENDPOINT from the PUSH CLIENT and shall register two callback functions, one for receipt of the ENDPOINT, and a second for handling of a VERSION EVENT | |||
* If not already present, PUSH CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID) | |||
* PUSH CLIENT shall generate a unique UUID4 Identifier for the APP (<abbr title="Previously known as the CHID">APPID</abbr>) | |||
* PUSH CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the PUSH SERVER | |||
* PUSH SERVER shall create an ENDPOINT for the UAID and APPID and return it to the PUSH CLIENT. | |||
* If a KICK driver is present, PUSH SERVER shall relay appropriate information. | |||
* PUSH CLIENT tenders the ENDPOINT to APP via callback. | |||
* APP sends ENDPOINT to the APP SERVER | |||
* On VERSION EVENT, APP SERVER PUTs version value to ENDPOINT | |||
* If a PUSH CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | |||
* If a PUSH CLIENT is NOT currently connected, an optional, proprietary KICK driver may be called to wake devices associated with the corresponding ENDPOINT UAID. | |||
* If a PUSH SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | |||
* PUSH CLIENT connects to the PUSH SERVER and shall identify a list of one or more UAIDs it is responsible for. | |||
* If there are VERSION EVENTS pending for requested UAIDs, PUSH SERVER sends an UPDATE packet (For this template, italicized names would be replaced by actual values): | |||
{ <i>UAID</i>: { | |||
{<i>APPID</i>: <i>VERSION</i>}, | |||
... }, | |||
... } | |||
* If no VERSION EVENTS are pending for the requested UAIDs, PUSH SERVER may return a status indicating no data available (for REST implementations) or simply not return content (for WebSocket) | |||
* During the transmission of the UPDATE, a PUSH SERVER may wish to return a 503 (Service Unavailable) error to APP SERVERS for any VERSION EVENT associated with an in progress UAID, so as to prevent potential race conditions. | |||
* On receipt of UPDATE, PUSH CLIENT shall return an ACK to the PUSH SERVER. | |||
* The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | |||
* The PUSH SERVER shall then clear APPID version information from short term storage, and re-allow version updates for those UAIDs if currently blocked. | |||
* The PUSH CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION | |||
NOTE: a PUSH RELAY may be created by combining the polling aspects of the PUSH CLIENT with the data management and KICK driver of the PUSH SERVER. This would allow a VERSION EVENT system to enter protected networks or use restricted means to communicate to USER AGENTs. It is important to note that once a PUSH SERVER has received an ACK for a given UAID, the PUSH SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the PUSH RELAY's problem. | |||
=== Data Schema === | === Data Schema === | ||
<i>How will data be stored</i> | <i>How will data be stored</i> | ||