CloudServices/Roadmaps/EditionServer: Difference between revisions

Jump to navigation Jump to search
no edit summary
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>Edition Server</i></h1>
<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 "Edition Server"?===
===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 Edition Server will make a best effort to deliver to the App.  
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 EditionServer 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 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 EditionServer, 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 EditionServer relays to <i>App</i> which then updates itself using "Not-Part-Of-This-Protocol-Either".
<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.  
;EDITION CLIENT: The application or library that acts as the intermediary between the APP and the EDITION SERVER. This provides the APP with VERSION EVENT callbacks.
;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.
;EDITION SERVER: The application or library that acts as the intermediary between the APP SERVER and the EDITION CLIENT. This provides ENDPOINTs for the APP SERVER.
;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:EditionServerDiagram.pdf A diagram of the EditionServer interaction points.]
[File:PlaceHolderServerDiagram.pdf A diagram of the PlaceHolderServer interaction points.]
# 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
# 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, EDITION CLIENT shall generate a unique UUID4 Identifier for the UserAgent (UAID)
# If not already present, PLACEHOLDER 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>)
# PLACEHOLDER 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
# PLACEHOLDER CLIENT shall send UAID, APPID and any additional information required for proprietary KICK to the PLACEHOLDER SERVER
# EDITION SERVER shall create an ENDPOINT for the UAID and APPID and return it to the EDITION CLIENT.
# PLACEHOLDER SERVER shall create an ENDPOINT for the UAID and APPID and return it to the PLACEHOLDER CLIENT.
# If a KICK driver is present, EDITION SERVER shall relay appropriate EDITION CLIENT provided information to the KICK driver.  
# If a KICK driver is present, PLACEHOLDER SERVER shall relay appropriate PLACEHOLDER CLIENT provided information to the KICK driver.  
# EDITION CLIENT tenders the ENDPOINT to APP via callback.
# 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 EDITION CLIENT is currently connected to APP SERVER, APP SERVER relays an UPDATE containing currently pending VERSION EVENTS.
# If a PLACEHOLDER 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 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 EDITION SERVER is unable to immediately deliver a VERSION EVENT, the VERSION EVENT is logged to short term storage.
# If a PLACEHOLDER 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.
# 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, EDITION SERVER sends an UPDATE packet (For this template, italicized names would be replaced by actual values):
# 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, EDITION SERVER may return a status indicating no data available (for REST implementations) or simply not return content (for WebSocket)
# 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 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.
# 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, EDITION CLIENT shall return an ACK to the EDITION SERVER.  
# 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 EDITION SERVER shall then clear APPID version information from short term storage, and re-allow version updates for those UAIDs if currently blocked.
# 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 EDITION CLIENT shall then notify APPs of the VERSION EVENT using the appropriate callback, and passing the VERSION
# The PLACEHOLDER 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 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==
Confirmed users
1,022

edits

Navigation menu