On Tue, 2005-10-25 at 11:50 -0500, Paul Kuliniewicz wrote:
> As the developer(s) of Rhythmbox Applet, I've been considering the
> opposite approach: split Rhythmbox into two separate programs: a backend
> server and a GUI.
>
> The backend server would handle managing the music library, playlists,
> and music playback. It wouldn't have a user-visible interface, but
> would communicate with other applications over D-Bus.
>
> The GUI as we know it today would then become just another client of the
> backend's D-Bus interface, just as Rhythmbox Applet is now. The user
> could then use the "official" Rhythmbox GUI, the applet, or some other
> program to control the backend server, which would be completely
> invisible --- the user would just notice that the official GUI, the
> applet, and so on would all have the same view of his music library.
This gets brought up every now and then, and it's an interesting idea.
The way Rhythmbox is designed would facilitate this, because it's
reasonably easy to see what belongs where.
rhythmdb, metadata, player - backend
lib - common to both
daapsharing - backend
podcast - obvious which belong in each
iradio - should be merged into widgets
widgets - frontend
Play orders belong in the backend, as does the removable media manager.
The playlist manager would need to be split up and merged into rhythmdb
and the main shell - which probably should happen anyway. The shell
itself, and shell-player, are frontend things.
Sources would also need to be split up; the backend bits being the
loading and creation of entries, the frontend being the presentation to
the user.
There are some things that we'd need to think hard about, particularly
how browsers and the search box would work. They should probably be
front-end specific, but the back-end needs to know about them, so that
they will affect the play order. Playlists present a similar problem.
I'd say that this should be a long-term goal, rather than something that
we want to concentrate on too early. However a lot of the actual work
can be done now, in parallel with the usual development; e.g. being able
to run and use queries via dbus, making various parts obviously back- or
front- end.
> One possible problem with this decoupled approach is, what happens if
> the backend is playing and all clients are closed? If you keep playing,
> then the user has no obvious way to stop that --- it's hardly intuitive
> to start a new program to stop something from running. You may need to
> keep *something* around that the user can see. Unless you have the last
> client stop playback before it terminates.
To me the obvious thing to do is stop and shutdown when the last client
disconnects. If you have an applet, or permanent-tray-icon-program,
there will always be a client so it will keep running, and if you use a
"normal" window-based interface it will quit when you close the window.
> And if you really want to run with this, why should the Rhythmbox
> backend be responsible for managing the local music library? What if
> the backend just relied on Beagle to index the local music collection
> and queried that as necessary? Then the backend only needs to keep
> track of what sources of music are available: local disks via Beagle,
> music shares via DAAP, radio streams via HTTP, portable media players
> via HAL, etc. And building playlists, of course.
It depends exactly what you mean by "managing" the local library. If you
just mean noticing when the use has gotten some new music, it can pretty
much do that now - by telling RB "add this to the library"
If you want to use it for more than that, such as managing the automatic
playlists, I don't know if it will work too well. The infrastructure for
automatic playlists is used by several other things (the browsers, other
sources) and I don't know if Beagle could take over that.
However getting Rhythmbox integrated with Beagle might be an interesting
project, and there are a couple of things that spring to mind:
* Having Beagle notify Rhythmbox of new music
* Giving Beagle access to the extra metadata stored in the Rhythmbox
database
* Being able to search for things with Beagle, and make a playlist out
of it, or play it, or whatever.
But I don't know too much about Beagle myself.
Cheers,
James "Doc" Livingston
--
You wouldn't know a subtle plan if it painted itself purple and danced
naked on top of a harpsichord singing 'Subtle Plans Are Here Again'
-- Lord Blackadder
Attachment:
signature.asc
Description: This is a digitally signed message part