Provide USCS API and browser communication pattern documentation

[wzin]

Overview:

Liquid Galaxy content state management is based on USCS messages. The documentation for USCS is provided on [lg_ros_nodes wiki](https://github.com/EndPointCorp/lg_ros_nodes/wiki/Unified-State-Control-System-API but there are some concepts that need additional coverage for Liquid Galaxy content creators. These concepts are listed below as requirements.

Requirements: document following patterns:

• providing data source for scenes to launcher JS application. Pattern overview:
  • launcher is an application running on display and kiosk
  • display view needs to have it's data pulled from a URL
  • kiosk view needs to have its data pulled from a URL
  • document mechanism of providing URL to repository of scenes via GET arguments
  • document data structure of a scene (and/or) document high level angular getter for that
• inter-browser ROS communication (ROS javasript + websocket rosbridge demo) for launcher applications. Launcher application has certain states that it's in that should be driven by ROS topics:
  • /activity/active boolean topic can tell if there's someone using peripherals or standing next to portal (think of it as a topic for triggering screensaver)
  • a topic like /launcher/scene is a perfect place to send string messages containing information about what's currently in launcher's focus to sync launcher browser instances between kiosk and the display
• launching apps
  • launching applications from the launcher will most likely emit a USCS message that will wait for apps to load in the background and show browsers on the screens as soon as the apps are ready - instruct user that there's a /director/ready ROS topic that launcher can subscribe to, in order to "know" when their app got ready (to show loading action). This topic will contain scene's slug as soon as scene has been loaded.
  • instruct developers that certain buttons that switch user between views should contain special messages e.g. return home will most likely send a USCS message containing a scene with launcher (as opposed to an application that user returns from)

Development notes

Document all this on a wiki so it's reusable. We've written tons of such documentation in the past in private repos.

Testing scenario

Go forth and slay dragons. If they're slayed then tests have passed.

[axisofentropy]

@wzin I don't think I'm in a good position to document this because I'm not familiar with any of those requirements. Do all those features even exist?

Is this part of the new Portal Launcher project?