Bandshell API?

[kench]

After speaking to Brian M last weekend about the proposed Chromecast application, @bamnet talked about the existence of 2 different "player" HTML front-ends, the code packaged as a part of Bandshell, and the code in the Concerto Prelude repository.

We proposed two options to merge these two codebases together.

• Option 1: Pull the HTML out of Bandshell and package Prelude with it.
• Option 2: Merge Prelude into Bandshell.

I think that option 1 makes more sense since we can separate the player code away from the player management and monitoring that Bandshell is designed to do. Prelude already supports building a Chrome CRX extension/app or serving the code out via an HTTP server and can easily be extended to build a Chromecast application.

The Option 1 Proposal that I am asking for would involve exposing Bandshell functionality via an HTTP/Websocket API that the Chrome app would talk to, receiving information such as the screen MAC address, Concerto server endpoint, and screen configuration. Placing the front-end code in a Chrome app provides a deeper level of integration than what was previously possible (open tab, reload page, etc.)

In the future, maintaining a single client-side player codebase and controlling runtime behavior via dependency injection (toggling Bandshell integration, support code for HTML5-over-localhost-HTTP-server/Chromium/Chromecast application) would be good direction going forward.

For @augustf, @bamnet, and @mikldt, does this design sound like something we should pursue?

[mikldt]

I'm a big fan of DRYing up our code base but I think this one might be a little bit of a stretch.

To summarize what I said at the meeting tonight, I think that there might be less commonality here than it would seem at first. Yes, both the chromecast/chromium/ipad app, and Bandshell need to input and store the location of the server. But the bandshell HTML interface really has a great number of additional responsiblities:

• Control of hardware (screen on/off, volume, etc.)
• Control of networking parameters
• Remote status monitoring of Bandshell as well as the PC itself
• Eventually, download and update of player software, drivers, etc.

I think the additional functionality that Bandshell requires in an HTML frontend would eclipse the current complexity of the frontend for something like prelude. As a result, it seems likely that making the code generic enough to serve both needs would require a lot more work than just duplicating the graphical assets and the storage of the server and identity information.

I also think we need to be careful about how we manage the complexity of Bandshell. Adding a dependency at the browser or level, or adding another webserver, would introduce new points of failure and make it even more difficult to diagnose the problems. I think a lot of endpoints will require similar functionality, and could be well served by some code sharing - we've talked about screensavers, ipads, chromecasts, and more. However, I think that PC/bandshell configuration is sufficiently distinct, and will be sufficiently widely used, to warrant a dedicated approach.

[kench]

However, I think that PC/bandshell configuration is sufficiently distinct, and will be sufficiently widely used, to warrant a dedicated approach.

After tonight's discussion, I agree with your point. There's a lot in Bandshell that I don't expect to expose in Prelude. However, I am curious to see if there's an API endpoint in Bandshell that exposes the current MAC and IP addresses and configured Concerto server.