The Concerto Frontend is the software that does the actual display of content on screens, in a traditional "digital signage" format. It is a web-based client to Concerto, using HTML and javascript to render and rotate through content at various intervals.

Requirements

• The Frontend must be compatible with the latest versions of popular browsers, so that is possible for a user to deploy an ad-hoc screen by navigating to a page and opening a full-screen browser. In addition, it will need to work with the browser distributed with the Concerto Player Software
• The Frontend must be able to render any number and arrangement of fields as described by the template.

Technology

The Concerto Frontend will use HTML and Javascript to render content. Currently we are using Google Closure, but consideration was given to jQuery (used in Concerto 1) and Backbone.

Application Interface Proposal

For a basic Concerto Screen, the browser will first load the Concerto HTML/javascript application. For full security, the application should be provided the following from a local data source (or hash-argument to the browser)

• Screen ID

• Pre-shared secret key unique to this screen

The application will act as the client for the upcoming transactions, which will take place using asynchronous requests.

0. /frontend/:screen_id bootstraps this entire process.

1. Client GETs /frontend/:screen_id/auth_request.json?host_challenge=:host_challenge

   • :screen_id is a unique identifier for the Concerto Screen

   • :host_challenge is a randomly generated challenge string for the screen to sign

   • Response from host:

     • :host_hash, which is :host_challenge hashed with the secret key for this screen

     • :client_challenge, a randomly generated string that the client must now hash

2. If the host's hash matches, the client GETs /frontend/:screen_id/auth_complete.json?client_hash=:client_hash

   • :client_hash is the hash of the pre-shared screen key with the :client_challenge

   • If the hash matches, the host responds by indicating a successful status and setting a session cookie for the host

3. The client GETs /frontend/:screen_id/setup.json (with configuration cookie).

   • If the cookie is valid, the host responds with general settings, backgroud information, and field information.

   • This request will recur periodically to make sure that any changes to the screen are reflected in a timely manner.

4. For each field, the client will make a request to /frontend/:screen_id/fields/:field_id/content?num=:num. The response will consist of an array of the next :num items (as determined by the appropriate sorting algorithms) to be displayed and the duration for each. If :num is omitted, it will default to 1. The request will be repeated every time more content is needed. If the server is not reachable the client may loop previously-shown content for that field.

---

• Maybe we can do this RESTfully by using URLs like /frontend (handles auth/ident/bootstrap only), then to /frontend/:screen_id/config, /frontend/:screen_id/fields/:field_id/next_content. ~BAM

• I'm not sure I'm a fan of downloading the timeline client side, or even relying on an exposed timeline by default because it forces any content ordering algorithm to operate on the entire set of available content and has consequences for moderation and expiration. I like next_content better, or something less stateful, where we can build a historical timeline client-side for offline / rewind purposes. ~BAM

Shuffling

By default, every field will shuffle the content from all of its feeds according to the weight assigned to the feed to which the content belongs. However, a number of options will be available to modify this behavior.

• Multi-page content: A content sequence that will be submitted at once and moderated as a single piece of content. Unless the feed subscriber has decided to limit content to one page (either by disallowing multi-page content, or setting a flag to only show the first page, for interactive cases where a user could click through to see the rest of the pages), these pages will always be displayed in sequence on the screen.

• Ordered subscriptions: A field may be either be configured to interleave the content from all its feeds, or to instead display all the content from each feed before moving onto the next. The order of feeds would be configurable.

• Ordered feeds: A feed may be configured so that all of its content is always displayed in order, rather than shuffled. If the subscription is interleaved but points to an ordered feed, the content from that feed will be displayed in the correct order, but content from other feeds will be interspersed within that order. The order of content within an ordered feed should be configurable from the moderation page.