I'm not fully sold on the name for this project so far, and I'd like to explore/brainstorm potential new names.

In particular, the .rs suffix bothers me, and I'm also concerned about potential trouble from having the substring scrobble in the name..

It would be nice to have an https://listenbrainz.org/ as target option, this service is more lively than gnu-fm.

Design the backend event loop for the scrobble.rs daemon - concept thus far:

• Loop over events from music sources (MPD, MPRIS).
• Send music events (Song changes, Song finished) to source queue for processing.. eventually to be sent to a target.
• Process client program commands, such as pausing the scrobbler, or holding all scrobbles in a queue.

This will act as a source for scrobble.rs, but if a library is developed before my library is ready, then that one will be used instead.

scrobble.rs will use a SQLite database to store music data in, as well as scrobble history and other data, using Diesel.

Further to this goal, a SQL schema will need to be designed and packaged for deployment with scrobble.rs.

For the initial implementation of scrobble.rs, I'm going to use Cargo/Rust's --features flag to compile specific sources and/or targets into scrobble.rs.

However, I'd like to have a look at using dylib to insert sources and/or targets on-the-fly.

This will act as a source for rscribble.