CloudServices/Roadmaps/EditionServer

Edition Server

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.

Why "Edition Server"?

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.

And "Version Control Server" had baggage issues of it's own.

Project Contacts

Principal Point of Contact - Doug Turner dougt@mozilla IRC - #channel Group Email - TBD

Goals

Apps need to know when something happens on their servers. One way to do that is to poll relentlessly back to their servers. The problem with that is that with each app performing it's own poll, you can wind up with a tremendous amount of traffic, all consisting of "Anything yet?" "Nope."

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.

There are a few Caveats that should be stated:

• Version Events are lossy.
  • A Version Event may expire before reaching the App. (You probably don't care about a traffic accident that happened a week ago.)
  • A Version Event may be lost due to intermediary server error.
  • The App should reconnect with the App Server in order to provide positive confirmation of an Event, the App Server may retry sending an Event to the App if this confirmation does not occur.
  • While best effort will be made to reduce the possibility, an App may receive the same or only slightly different Version Event in rapid succession. It is advised that the App and App Server use a method to only act on the highest Version.
• Version Events, and the information around them are not encrypted. Since this is a low information system, it is strongly encouraged that information that requires security ONLY be exchanged between the App and the App Server using properly secure methods.
• Endpoints may be used to identify individual users. Since the service's role is to alert apps to connect back to the AppServer (and thus expose additional info such as the IP address, MAC, and any account info), it was felt that this is should not surprise users and implementers.

Use Cases

How will this be used?

Definitions

ACK

An acknowledgement message.

APP SERVER

A possibly third party provided server that provides information to the APP. The originator 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.

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.

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.

ENDPOINT

A URL which accepts VERSION updates to trigger eventual APP VERSION EVENT.

UAID

A globally unique identifier for a given User Agent.

VERSION EVENT

A request from APP SERVER to notify an APP to take action.

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 (APPID)
• 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):

{ UAID: {
   {APPID: VERSION}, 
   ... },
  ... }

• 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.

Get Involved

Call to action for folks who want to help.

Design

Points of Contact

Server Engineer - "trink" trink@mozilla Server Engineer - JR Conlin jrconlin@mozilla Client Engineer -

API Reference/Documentation

Data Schema

How will data be stored

API

How to call the data

method URI

description

Arguments argument descriptions
Returns: returned contents

Platform Requirements

What are the things this needs (OS, language, databases, etc.)?

Libraries Required

List of external project dependencies. (Stuff that's not pulled in via the installation script)

Code Repository

Links to the published code bases

Release Schedule

Predicted code delivery dates

QA

Points of Contact

Engineer - Name contact@info

Test Framework

Security and Privacy

Fill out the security & privacy bug template: https://bugzilla.mozilla.org/form.moz-project-review (https://wiki.mozilla.org/Websites/Kick-Off_Form)

Points of Contact

Questionnaire Answers

1.1 Goal of Feature

2. Potential Threat Vectors and Mitigation Points

Review Status

Bugzilla Tracking # - see https://wiki.mozilla.org/Security/Reviews

Issues and Resolutions

Operations

Points of Contact

Deployment Architecture

Bugzilla Tracking # -

Escalation Paths

Lifespan Support Plans

Logging and Metrics

Points of Contact

Tracking Element Definitions

Data Retention Plans

Dashboard URL

Customer Support

Points of Contact

Sumo Tags

Review Meeting