mikldt
commented
10 years ago 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
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.
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?