Milestone: Proof of Concept

Goals

The goal of the proof-of-concept milestone is to establish the technical feasibility of the project and to come up with a preliminary design for the components of the software.

Issues Solved

• (#1) Develop a working player status interface. The original intention here was to develop a scheme whereby the player status could be reported to the front-end using two approaches: a polling based approach that would occur at a set interval to make sure that elements of player status like elapsed time would stay synchronized, and an event-based approach that would notify the player of major changes, such as track and playlist changes. Unfortunately the desired event-based technology that I wanted to use (HTML5 Server-Sent events) is poorly implemented in most browsers and was unfit for use in the proof-of-concept. Some further investigation may be warranted in this area, as other technologies like WebSockets or older forms of COMET like AJAX long-polling exist; however, more aggressive polling will be a technically simpler solution and also feasible since the web application is not expected to support a large number of users and can make effective use of caching semantics to reduce network traffic effectively to only report changes.
• (#2) Establish a preliminary database schema to start storing information. This is expected to change a little bit over time.
• Provide a basic front-end for display of the player status feature.
• (#4) Show the logged in user's play queue statically (does not update until the next page load)
• (#5) Show the global play queue statically (does not update until the next page load)
• (#6) Provide a simple mechanism for adding tracks to the play queue and ensuring they get added to the Mopidy play queue. This first iteration supports adding tracks by Spotify URI, as this is the only track add endpoint that will be needed in the application. The front-end at this stage only supports adding Spotify URIs directly, but should eventually support things like track searching with the Spotify URI associated with search results but not necessarily specifically showed to the user.
• (#7) Establish a way of ensuring consistency between the Partify play queue and the Mopidy play queue. The solution to this issue was to make the Mopidy play queue authoritative and assume that no changes to the Mopidy play queue will happen outside of Partify. The Partify play queue is then augmented with the Mopidy track ID and a corresponding entry is checked for in the Partify database with a Mopidy track ID. Entries without track IDs in the Mopidy playlist are removed and consistency between playlist entries is verified. The current implementation has the potential to be database-intensive if called a lot, and as such should be called as infrequently as is necessary.
• (#12) Documentation.
• (#13) Provide event-based subscriptions to Mopidy events. A thread is spawned with the start of the Partify application that continuously issues and IDLE request to the Mopidy server, asking it to wait for any event in any subsystem of the Mopidy application. This allows for event-based updates to be processed from Mopidy to perform functions like playlist consistency checking. A framework could easily be placed on top of this to allow functions to subscribe to certain events (using decorators and the like) if needed in the future, but no near-term need for this system was identified.