Confirmed users
1,018
edits
Line 55: | Line 55: | ||
;VERSION EVENT: A request from APP SERVER to notify an APP to take action. | ;VERSION EVENT: A request from APP SERVER to notify an APP to take action. | ||
==Requirements== | ==Requirements== | ||
# APP requests an ENDPOINT from the EDITION 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, EDITION CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID) | |||
# EDITION CLIENT shall generate a unique UUID4 Identifier for the APP (<abbr title="Previously known as the CHID">APPID</abbr>) | |||
# EDITION CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the EDITION SERVER | |||
# EDITION SERVER shall create an ENDPOINT for the UAID and APPID and return it to the EDITION CLIENT. | |||
# If a KICK driver is present, EDITION SERVER shall relay appropriate EDITION CLIENT provided information to the KICK driver. | |||
# EDITION 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 EDITION CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | |||
# If a EDITION CLIENT is NOT currently connected, an optional, proprietary KICK driver may be called to wake devices associated with the corresponding ENDPOINT UAID. | |||
# If a EDITION SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | |||
# EDITION CLIENT connects to the EDITION SERVER and shall identify a list of one or more UAIDs it is responsible for. | |||
# If there are VERSION EVENTS pending for requested UAIDs, EDITION SERVER sends an UPDATE packet (For this template, italicized names would be replaced by actual values): | |||
{ <i>UAID</i>: { | { <i>UAID</i>: { | ||
{<i>APPID</i>: <i>VERSION</i>}, | {<i>APPID</i>: <i>VERSION</i>}, | ||
... }, | ... }, | ||
... } | ... } | ||
# If no VERSION EVENTS are pending for the requested UAIDs, EDITION 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 EDITION 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, EDITION CLIENT shall return an ACK to the EDITION SERVER. | |||
# The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | |||
# The EDITION SERVER shall then clear APPID version information from short term storage, and re-allow version updates for those UAIDs if currently blocked. | |||
# The EDITION CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION | |||
NOTE: a EDITION RELAY may be created by combining the polling aspects of the EDITION CLIENT with the data management and KICK driver of the EDITION 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 EDITION SERVER has received an ACK for a given UAID, the EDITION SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the EDITION RELAY's problem. | NOTE: a EDITION RELAY may be created by combining the polling aspects of the EDITION CLIENT with the data management and KICK driver of the EDITION 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 EDITION SERVER has received an ACK for a given UAID, the EDITION SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the EDITION RELAY's problem. |