New browser client - Githubissues

sampsyo commented 10 years ago

This is a subtask of the next-generation web interface effort (#718).

We should design a new browser interface to go with the new HTTP API. This can start with interface design before the API itself is in place.

It should support:

[ ] Browsing and querying items (like the current interface) and also albums, ideally with a nice album art display.
[ ] Playing music in the browser.
[ ] An interface to the importer. This part seems very hard, so maybe it's best left to the end?

jonathanthomas83 commented 10 years ago

Awesome!!! Now we're talking my language! :-)

sampsyo commented 10 years ago

@jonthomas83 :smiley:

I forgot to mention: here are obviously no constraints on technologies or frameworks to use here. If you like Angular or Ember or whatever, feel free to start there as far as I'm concerned!

canpolat commented 10 years ago

How about having the option for playing music remotely (on the server)?

jjrh commented 10 years ago

notifications@github.com writes:

How about having the option for playing music remotely (on the server)?

Personally I think this is a far more important feature than being able to play audio through the browser.

It shouldn't be all that much work, this would be tied to the API which would make calls to mpd/bpd. There are existing python libraries for this.

sampsyo commented 10 years ago

Yes, good point! It would be great to reuse the same browsing interface for both purposes. (#736 mentions this as an extension to the API also.)

PierreRust commented 10 years ago

Concerning playing music on the server, I think it would not directly be part of the HTTP API. I believe it would be better implemented using the Plugin API for extending HTTP interface (see #739) :

a player plugin would expose some actions for playing music (play, stop, next, add item to play queue, etc.)
these actions are integrated into the HTTP interface
the Web client can use this to play music on the server when he detects the player plugin is available

As a conclusion : yes, server-side playing support should be implemented in the browser client, but we first need :

to define the plugin API : #739
to implement a player plugin (which could probably be based on the current BDP plugin) - we could create a new issue for this.

sampsyo commented 10 years ago

All good points. In fact, in that direction, we would be remiss not to look at the Mopidy project, which shares much of the spirit of beets and already has (a) a working server-side player in Python and (b) a clean web API design. Maybe it's not worth reinventing all this. I'm not sure what an integration would look like, but hopefully we can make beautiful music together.

PierreRust commented 10 years ago

Correct me if I missed something, but from what I've read mopidy's API is simply exposing their core API on websocket, using JSON-RPC. This approach make the (no-so) web API very dependent on the internal API and is completely different from what we are planning to do (that is, a REST API). IMO websockets are great for (optional) server-sent notifications (avoids polling) but (a) not so good for a complete API and (b) still lack decent support, especially on mobile browsers.

The serve-side player is probably something we should look at, I was thinking at the current BDP plugin but maybe do you think it's not mature enough ? (I never really used it).

jjrh commented 10 years ago

notifications@github.com writes:

The serve-side player is probably something we should look at, I was thinking at the current BDP plugin but maybe do you think it's not mature enough ? (I never really used it).

Someone suggested we make the server side player be a separate plugin which would extend the HTTP API. I don't see any reason why one of the many MPD python modules would not work with BPD.

Am I missing something here?

-jjrh

PierreRust commented 10 years ago

It's me who suggested to make the server side player a separate plugin (let's call it server-player).

I'm not sure I understand what you mean. The BDP plugin exposes an interface that implements mpd's protocol, so it can certainly be used with an MPD python module, but as the serve plugin and the server-player would run in the same beets instance, I don't really see the point in using another socket based protocol to communicate between them, is that what you had in mind ?

canpolat commented 10 years ago

I guess all of you are aware of the MPRIS specification, which is supported by all major players in the Linux world. I even thought of implementing an MPRIS plugin for beets at some point, but had other priorities at the time. Once the browser client is ready, I can return back to this topic, I suppose. This is not strictly relevant to what you are discussing, but IF there will be a change in the protocol, here is another one to look at.

PierreRust commented 10 years ago

I've been thinking at MPRIS too, and I think there are two different use-cases here :

beets (with player plugin) is running on the same computer than the MPRIS client (typically some kind of applet like the sound menu on ubuntu) : in that case the MPRIS interface can be implemented directly as a plugin and exposed locally on dbus.
beets is running on a separate system (like a headless raspberry for example) and you want to control it from your main computer. In that case you need a program on that computer that exposes the MPRIS interface locally and communicates with the remote beets instance, possibly with the HTTP interface.

jtemplet commented 9 years ago

Is anyone still working on an overhaul of the UI for the web?

I was thinking that we should start breaking these into smaller pieces instead of a giant piece of software. In other words, the web-plugin would be in a different repo from beets itself. The benefit of this is the Web team can iterate faster since it's a subset of a giant codebase. This is a philosophy the node.js ecosphere has taken up.

I personally am interested in just a better UI for mining the data in the beets library.

sampsyo commented 9 years ago

Hi, @jtemplet! As far as I know, no one has started work in earnest, but I suggest you coordinate with @webpro (c.f. #1002), who has recently been interested in the same thing.

We have talked about splitting off the frontend into a separate repository, and I would love to see this happen. We will still ship beets with the server, but the JavaScript and stuff should be totally separate. And FWIW, the work on designing the server component involves AURA.

Shall we kick this off by starting a new repository and doing some rough design?

jtemplet commented 9 years ago

@sampsyo I always think of solutions in a top down manner, so I started browsing some bootstrap themes for ideas. This layout piqued my interest http://ironsummitmedia.github.io/startbootstrap-sb-admin-2/pages/index.html I would love to have features like background jobs, notifications, reports, charts, etc.

Maybe the first thing it would support is doing a (sorry, I haven't dug into the exact nature of the API) GET /song and it would basically get all the songs, pagination, sorting, all that junk and you can drill down and get all the song info; this would all be read only.

Since this would be one-way binding, I was thinking about using Backbone.js. I'm more familiar with Knockout.js, but since that provides 2-way data binding, it may be unnecessary.

I don't think using Angular is a good idea because it would be total overkill.

I can start a new repo and start making some feature requests. Thoughts?

sampsyo commented 9 years ago

Sounds great! And yeah, that's a nice layout inspiration. It will be awesome to see what you put together; I'm excited to work on this!

FWIW, the endpoint for getting all the songs in AURA (the new protocol) is almost exactly what you're proposing, just with a different name: GET /aura/tracks. See: http://auraspec.readthedocs.org/en/latest/api.html#tracks

jtemplet commented 9 years ago

Thanks @sampsyo Here is the new repo https://github.com/jtemplet/beets-web The python code has been imported and I dropped in the bootstrap theme.

Next is to hook up the UI to the backend. I will also need to hookup the python code to the DB/DB wrapper. Is this part of the code modularized?

sampsyo commented 9 years ago

Cool! I'm excited to see how this goes.

About the database wrapper: I would actually recommend keeping the frontend (in-browser, HTML/CSS/JavaScript) bits strictly separate from the backend (the Python part). The idea in this series of tickets is that beets will ship with the Web server—the Python bits—but not with any frontend. This is because the same API will be used for many different purposes, not just the browser player.

So feel free to play around with modifying the current Flask app for now (to answer your question: yes, the beets library has a mostly stable interface), but eventually, we should separate the two components.

jtemplet commented 9 years ago

@sampsyo I just wanted to follow up on the progress I've made with the new web client. In the README I wrote directions on using the new web client. It's kind of a pain until we figure out a better way to have them separate.

So far, the web client will query the backend for songs, albums and artists (under 'Tables'). You can also get a detailed view of a song or album by clicking on the table row. There's still a ton to do, but I'm happy with the progress that's been made thus far. :) Let me know if you have any issues.

https://github.com/jtemplet/beets-web

sampsyo commented 9 years ago

Wow, this is very cool! I haven't had a chance to play with it in too much detail, but the progress looks awesome. I'll make sure it's on my to-do list to work on making that setup procedure less onerous…

jonathanthomas83 commented 9 years ago

I've sent out an initial email regarding requirements gathering for making informed decisions - will hopefully yield some good feedback, please help out with that if you have ideas. I'll put together some initial wireframes based on what I get back.

@jtemplet I like your work so far, I particularly like your ideas for extra features such as charts etc, that sounds great.

jtemplet commented 9 years ago

I didn't get an email regarding the requirements.

On Wed, Apr 1, 2015 at 7:09 AM, Jonathan Thomas notifications@github.com wrote:

I've sent out an initial email regarding requirements gathering for making informed decisions - will hopefully yield some good feedback, please help out with that if you have ideas. I'll put together some initial wireframes based on what I get back.

@jtemplet https://github.com/jtemplet I like your work so far, I particularly like your ideas for extra features such as charts etc, that sounds great.

— Reply to this email directly or view it on GitHub https://github.com/sampsyo/beets/issues/738#issuecomment-88498882.

sampsyo commented 9 years ago

@jtemplet It went to the mailing list: https://groups.google.com/d/msg/beets-users/YXz-LAfQrRs/9yhroO5WLc4J

mattmurch commented 7 years ago

Hey, what is current state of this? Is anyone currently working on improving the current web browser interface?

IrosTheBeggar commented 7 years ago

@mattmurch

I'm working on my own web interface called mStream. It has support for Beets built it..

https://github.com/IrosTheBeggar/mStream

laBecasse commented 3 years ago

I have created Beetle, a web interface on top of the beet web API. It supports album and artist querying, text-based search and current playlist management. You can see how it looks on the demo video.

I opened a discourse topic about it.

The source are on gitlab : https://gitlab.com/maxburon/beetle.

beetbox / beets

New browser client #738