jimankrom / sway Goto Github PK

As we now have grunt running a number of tasks, and both npm and bower package files, we should have a grunt master install task which runs both npm and bower install and runs ui and api tests to confirm the installation.

• Control interval settings (this should be dynamic, adjust to load)
• Current channel / status
• API map

On first authentication, Sway should drop a cookie containing a unique identifier. For any auth requests the user should submit the cookie.

If a timeout changes at runtime (to throttle system throughput, etc) each user should get updated with that.

This should NOT be solved by sending config on every request, only when the values have changed.

Closed as proven working by a6de164 .

Proceed to api/sway.config.json for configuration.

When an iphone user attempts to connect, the Sway server throws errors indicating that auth.uid is null.

The user.html page must send control messages to the sway control server.

Design a plug-in approach to actions, that could be output destinations

While this ticket should just be for the plugin approach, the intent should be to have the following output plugins available:

• OSC
• DMX
• I2C - rPi, Beaglebone I2C libraries would be killer
• MIDI (?)
• PixelPusher?

Chan 1 could send to OSC at resolume, etc., chan 2 to something else.

Users should be recognized by their cookie, if one exists.

Karma/Jasmine/Requirejs/Sinon

• Verify each are working in the test runner.

Name and notes should be pushed to the user's cookie as well.

The server must accept control messages and translate them into OSC messages, and send them.

This should be based on a configuration file.

After authentication, the user app should be notified of when they are calibrating or controlling the system.

While the user does not have control, it should poll an authorization service that returns a response stating that the user is authorized to be in control, or authorized to calibrate.

Calibration MUST override control.

The authorization response should also be returned upon a successful submission to the server.

Not having authorization should stop the client from sending any messages, and should poll the server for authorization.

If the server returns a BANNED authorization, the client should cease all operations.

Users in the queue that have stopped polling for more than ten minutes should be removed from the queue.

Upon opening the sway user page, the page should discover the server and authenticate the user by returning a token to the page.

See #13 for authorization scheme.

Use case:
User connects to the system.
Administrator grants the user 'calibrate' rights by selecting the user from a 'calibrate' dropdown and pressing an 'ok' button.
User's client app notifies the user to point to the "front" of the system, then to point to "west", then find the center and point directly up. (then maybe 'ground'?)
User then submits the data.

Current implementation has some support for cookies. This could be greatly improved.
User MAC addresses could be captured and stored in an optional database (using node-arp), along with some connection information (such as "Installations visited", etc).

Users could be remembered as donors, friends, family... even people that need to be prevented from connecting.

The administration page should be able to show the current messages that have been sent.

• Should only appear when the admin user wants to see it.
• Should only record when the admin user wants to log this information
• All output plugins should support some means of recording the past few seconds of data.

The userAgent string contains a number of items that Sway does not need. The User Control page should limit that data before requesting authorization from the Sway server.

Non-absolute devices must translate to an absolute position.

Some links
http://stackoverflow.com/questions/18112729/calculate-compass-heading-from-deviceorientation-event-api

Investigation / research task.

• What will this take?
• Is it viable?
• Is it accurate enough to make it worth pursuing? (and what -is- that threshold?)

For Video Bleep (videobleep.tv) we already have roughly guaranteed triangular points - the tripod setup. Could each tripod be given a wifi AP to triangulate from?

Some links:
http://trillworks.com/nick/2011/11/25/real-time-indoor-navigation-for-android-phones/
https://developer.mozilla.org/en-US/docs/Web/API/WiFi_Information_API

The Admin.html page should show a list of all users currently connected to the Sway control server.

The current list of live users is found at /users.

The user list must show user id and user agent; however the user agent string is long and in the future will be limited to just relevant information such as device information (see issue #5 )

When a user's screen locks, sway continues to send the same frame over and over.

This should
(1) Detect that the user is idle
(2) set a long timeout to delete the user completely
(3) set a short timeout to allow the user to control within a short recovery period.
(4) in between those two, have the user reconnect and re-queue.

What place am I in the queue?
How long it will be before I can control?

Grunt should get all packages (npm, bower(?)) for the UI, API and Test packages in the application.

• As UI does not run on node, bower should install all packages there.
• API should be installed via npm.
• Test should be installed via npm, however not every component we will use for UI testing is npm compatible - evaluate use of bower for install of those components (sinon especially).

This redirect can -only- be set once - when the user is added to the channel.

A user should see a description about the channel, and have a show/hide help link to see more.

The API test run on nodeunit, while the UI tests run on karma & jasmine.

Grunt should detect file changes within each folder and run the appropriate test runner.

As a result of a game event or other such event, sway should be able to tell the user's UI to launch a specific event.

An associative array should be able to handle this; Sway can attach an action message to the response containing the name of the plugin, and perhaps values.

example:
sway.user.actions = [{
"vibrate" : { "duration": 100 }
}]

Allow a range, offset, and scale for values.

I should be able to send users a message. Either send to one, all in a channel, or all users.

Build run from a grunt file.

All js files minified and concatenated.

** Debug
*** Server, User and Admin apps created with Debug modes
*** Capable of unit testing
** Production
*** No debug code included.

https://github.com/techpines/express.io

Currently sway.osc only supports one value per address. This should be improved to (greatly) reduce OSC traffic.

If Sway was to be applied to a game, one might think of each control channel as the individual instrument a single user controls.

A Channel is a bundle of control mappings; the user's input is mapped to one specific set of control message outputs.

All scripts used for the User Control page (user.html) must be concatenated and minified.

Currently;

• ui/scripts/sway.input.js
• ui/scripts/sway.user.js
  should be concatenated and then minified and put into a dist folder.

Various output destinations might include

• OSC
• DMX
• MIDI
• I2C
• Pixelpusher

Create sway.monitor.js

Create basic instrumentation / logging for a snapshot each second of:

• requests served
• user count
• users queued / dequeued

Design could be that a monitor snapshot object exists to gather these counts, and each second we add it to the logging array.

• Hang on to these value for the past n seconds (configurable)
• Allow charting it in the admin UI
• Allow actions based on certain thresholds of values.

Various plugins could handle:

• devicemotion events
• touch events
• geolocation events
• click events

For now this should exist on a page called ui/control.html.

This page should NOT send smartphone orientation control.

It was believed that the UI has knowledge of what data to subscribe to and send to the server; this is not true.