A fork of the beets web plugin meant to emulate foobar2k but on the web.
Need to figure out how the files in the beets web code are actually ran.
__init__.py in the web directory.
./beet web 0.0.0.0 8888 from the repository will include changes in the code. So, I can get started with development before figuring out how to make it work independently from beets.
I got this far:
>>> import beetsplug >>> from beetsplug import web >>> web >>> from beetsplug.web import WebPlugin >>> wp = WebPlugin() >>> wp.commands().func() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: func() takes exactly 3 arguments (0 given)
Those 3 arguments are
lib, opts, args where
lib is a beets library, and
args are suboptions and subarguments to the command line choice.
A key step in isolating the web plugin will be replacing the invocation with my own python script. But first, I will first need to remove all references to those parameters are their consumers from the web app.
I'm considering getting rid of beets web completely in favor of Clojure stack + Backbone. I did this, it went pretty well.
- implement /item/query/ response with files from disk
- consider the future including Zoia
- get app to play music from filesystem
- work on UI or work on API
Currently the beets web API comprises these models:
- items (files)
Additionally, there are one or more routes for each model which include queries on the models.
Which of these models/routes are actually used by the front end? Just these routes:
The front end merely sends a query to beets and outputs the response as a list of tracks. However, because it's coming from beets, there's tons of awesome metadata. We don't need all of it in order to play music. The minimal set of metadata items appears to be as follows:
Models in beets web:
- track (number)
- track total
- disc (number)
- disc (total)
- mb_trackid (musicbrainz entry)
- id (used for download:
href=item/<%= id %>/file)
In order to properly emulate foobar, we'll need most of the fields in ItemExtraDetail view.
- routes corresponding to resources
- functions to retrieve those resources
- possibly data transformations in between retrieval and response