Confirmed users
1,022
edits
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<span style="color:red">This is a draft document. It is a work in progress.</span> | <span style="color:red">This is a draft document. It is a work in progress.</span> | ||
<h1><i> | <h1><i>PlaceHolder Server</i></h1> | ||
==Overview== | ==Overview== | ||
Provide a service to allow Third Party Application servers to notify their Web Apps that an event has occurred and action may be required, without requiring a web page to be constantly present and connected to the Third Party Application Server. The Editon Server provides best effort to notify Apps of a version update, however delivery is not guaranteed. | Provide a service to allow Third Party Application servers to notify their Web Apps that an event has occurred and action may be required, without requiring a web page to be constantly present and connected to the Third Party Application Server. The Editon Server provides best effort to notify Apps of a version update, however delivery is not guaranteed. | ||
===Why " | ===Why "PlaceHolder Server"?=== | ||
placeholder is a temporary name while this document is being edited in order to prevent Wiki conflicts. | |||
In order to scale easily, a system should require the least amount of data necessary. While it would be ideal that there be no data exchanged, we realized that having a tiny amount would not alter the overall design or change the desired behaviors. | In order to scale easily, a system should require the least amount of data necessary. While it would be ideal that there be no data exchanged, we realized that having a tiny amount would not alter the overall design or change the desired behaviors. | ||
| Line 21: | Line 23: | ||
In addition, an App Server may wish to notify an App of an event or action and not be able to send a message directly to the App or device. | In addition, an App Server may wish to notify an App of an event or action and not be able to send a message directly to the App or device. | ||
To accomplish this, App Servers can send Version Events to Apps. A Version event is a simple, fire and forget "ping" style event that the | To accomplish this, App Servers can send Version Events to Apps. A Version event is a simple, fire and forget "ping" style event that the PlaceHolder Server will make a best effort to deliver to the App. | ||
There are a few Caveats that should be stated: | There are a few Caveats that should be stated: | ||
| Line 33: | Line 35: | ||
==Use Cases== | ==Use Cases== | ||
<b>An App wishes to be notified when new email arrives</b>. A User installs an <i>App</i> on a mobile device which notifies her when someone adds a note to her bulletin board. The <i>App</i> calls the Registration function, which returns an <i>EndPoint</i>. The <i>App</i> sends the <i>EndPoint</i> to the <i>AppServer</i> using the magic of "Not-Part-Of-This-Protocol". The <i>AppServer</i> stores the <i>EndPoint</i> in the User's information. When a new note is added, the <i>AppServer</i> fetches the <i>EndPoint</i> and PUTs a new version value to it. This alerts | <b>An App wishes to be notified when new email arrives</b>. A User installs an <i>App</i> on a mobile device which notifies her when someone adds a note to her bulletin board. The <i>App</i> calls the Registration function, which returns an <i>EndPoint</i>. The <i>App</i> sends the <i>EndPoint</i> to the <i>AppServer</i> using the magic of "Not-Part-Of-This-Protocol". The <i>AppServer</i> stores the <i>EndPoint</i> in the User's information. When a new note is added, the <i>AppServer</i> fetches the <i>EndPoint</i> and PUTs a new version value to it. This alerts PlaceHolderServer Client, which wakes the <i>App</i> and sends a version event via a registered callback. This causes the <i>App</i> to refresh it's messages (again using the magical "Not-Part-Of-This-Protocol" system), and User gets a screen full of adorable kittens. | ||
<b>An AppServer wishes to notify Apps of an update</b>. Since a server doesn't want to be deluged by millions of pings from devices every hour, the developers wisely decide to opt for a Push mechanism. Much like the other example, an <i>App</i> registers with | <b>An AppServer wishes to notify Apps of an update</b>. Since a server doesn't want to be deluged by millions of pings from devices every hour, the developers wisely decide to opt for a Push mechanism. Much like the other example, an <i>App</i> registers with PlaceHolderServer, gets an <i>EndPoint</i> which it relays to <i>AppServer</i>. <i>AppServer</i> then PUTs a '000' version to the <i>EndPoint</i> which triggers an "update" event for the App, which silently acknowledges that all is well. At some later time, <i>AppServer</i> PUTs '001' to the <i>EndPoint</i> which PlaceHolderServer relays to <i>App</i> which then updates itself using "Not-Part-Of-This-Protocol-Either". | ||
<b>An incoming request from a WebRTC </b>. Bob uses Ringo’s STAR webrtc service. Bob is using the Desktop browser, but the tab/window isn't open to the Ringo service. Alice makes a webrtc call from work to Bob. Bob sees a notification about an incoming call. | <b>An incoming request from a WebRTC </b>. Bob uses Ringo’s STAR webrtc service. Bob is using the Desktop browser, but the tab/window isn't open to the Ringo service. Alice makes a webrtc call from work to Bob. Bob sees a notification about an incoming call. | ||
| Line 50: | Line 52: | ||
;APP: A possibly third party provided Web Application located on a remote User Agent. The end consumer of VERSION EVENTS. | ;APP: A possibly third party provided Web Application located on a remote User Agent. The end consumer of VERSION EVENTS. | ||
;APPID: A globally unique identifier for a given App. | ;APPID: A globally unique identifier for a given App. | ||
; | ;PLACEHOLDER CLIENT: The application or library that acts as the intermediary between the APP and the PLACEHOLDER SERVER. This provides the APP with VERSION EVENT callbacks. | ||
; | ;PLACEHOLDER SERVER: The application or library that acts as the intermediary between the APP SERVER and the PLACEHOLDER CLIENT. This provides ENDPOINTs for the APP SERVER. | ||
;ENDPOINT: A URL which accepts VERSION updates to trigger eventual APP VERSION EVENT. | ;ENDPOINT: A URL which accepts VERSION updates to trigger eventual APP VERSION EVENT. | ||
;UAID: A globally unique identifier for a given User Agent. | ;UAID: A globally unique identifier for a given User Agent. | ||
;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== | ||
[File: | [File:PlaceHolderServerDiagram.pdf A diagram of the PlaceHolderServer interaction points.] | ||
# APP requests an ENDPOINT from the | # APP requests an ENDPOINT from the PLACEHOLDER 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, | # If not already present, PLACEHOLDER CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID) | ||
# | # PLACEHOLDER CLIENT shall generate a unique UUID4 Identifier for the APP (<abbr title="Previously known as the CHID">APPID</abbr>) | ||
# | # PLACEHOLDER CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the PLACEHOLDER SERVER | ||
# | # PLACEHOLDER SERVER shall create an ENDPOINT for the UAID and APPID and return it to the PLACEHOLDER CLIENT. | ||
# If a KICK driver is present, | # If a KICK driver is present, PLACEHOLDER SERVER shall relay appropriate PLACEHOLDER CLIENT provided information to the KICK driver. | ||
# | # PLACEHOLDER CLIENT tenders the ENDPOINT to APP via callback. | ||
# APP sends ENDPOINT to the APP SERVER | # APP sends ENDPOINT to the APP SERVER | ||
# On VERSION EVENT, APP SERVER PUTs version value to ENDPOINT | # On VERSION EVENT, APP SERVER PUTs version value to ENDPOINT | ||
# If a | # If a PLACEHOLDER CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS. | ||
# If a | # If a PLACEHOLDER CLIENT is NOT currently connected, an optional, proprietary KICK driver may be called to wake devices associated with the corresponding ENDPOINT UAID. | ||
# If a | # If a PLACEHOLDER SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage. | ||
# | # PLACEHOLDER CLIENT connects to the PLACEHOLDER SERVER and shall identify a list of one or more UAIDs it is responsible for. | ||
# If there are VERSION EVENTS pending for requested UAIDs, | # If there are VERSION EVENTS pending for requested UAIDs, PLACEHOLDER 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, | # If no VERSION EVENTS are pending for the requested UAIDs, PLACEHOLDER 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 | # During the transmission of the UPDATE, a PLACEHOLDER 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, | # On receipt of UPDATE, PLACEHOLDER CLIENT shall return an ACK to the PLACEHOLDER SERVER. | ||
# The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | # The ACK shall contain a list of UAIDs for which all APPIDs have been properly received. | ||
# The | # The PLACEHOLDER SERVER shall then clear APPID version information from short term storage, and re-allow version updates for those UAIDs if currently blocked. | ||
# The | # The PLACEHOLDER CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION | ||
NOTE: a | NOTE: a PLACEHOLDER RELAY may be created by combining the polling aspects of the PLACEHOLDER CLIENT with the data management and KICK driver of the PLACEHOLDER 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 PLACEHOLDER SERVER has received an ACK for a given UAID, the PLACEHOLDER SERVER is under no obligation to retain that data, and proper relay of the VERSION EVENT is the PLACEHOLDER RELAY's problem. | ||
==Get Involved== | ==Get Involved== | ||