Contributing to mpdel

[DamienCassou]

Hi,

I'm the author of mpdel and libmpdel. Very good naming choice with elmpd. It's refreshing to find someone who is as good as naming things as me :-).

Joke aside, if you want to contribute to libmpdel or mpdel, feel free to do so. I'm using these packages everyday and I regularly merge contributions from others.

Is there a reason why you decided to write your own library instead of building on top of an existing one?

Have fun hacking Emacs!

[sp1ff]

Hi Damien, it's a pleasure to meet you, since I've spent a good deal of time reading your code! I am an mpdel user, and read libmpdel.el closely before embarking on elmpd.
My take on mpdel is that it is a full-blown mpd client; something one might use instead of ncmpcpp, or mpc, say. As I experimented with my workflow, however, I found myself wanting less functionality: rather than interacting with a fully-featured client, I just wanted to skip to the next song while editing some code, for example. I customize my mode line heavily, and I wanted a little bit of logic to add the current track to the mode line & keep it up-to-date. I have written a companion daemon to mpd that maintains ratings & play counts; I just needed a little function that would let me rate the current track while I was reading mail (in Emacs).
My next move was to read through libmpdel for inspiration. Unsurprisingly given its role supporting mpdel, it offered a lot of features, defined a lot of abstractions used by mpdel & had opinions on how one should talk to mpd. For instance, libmpdel clients will perforce employ a single connection that generally idles, and only interrupts idling to issue commands-- i.e. it talks to mpd in the manner that mpdel does. To be clear, there's nothing wrong with that way of talking to mpd; it's just that other applications (mpdfav, e.g.) make different choices & I wanted a library that let me choose.
Having programmed other mpd clients, I knew what I wanted could be done with very little code & very few resources (for context, I've scripted mpd in bash by just echo'ing the commands to /dev/tcp/$host/$port). I spent time earlier this year learning to write asynchronous Rust, and that inspired me to see how simple I could make this using just callbacks. elmpd exports just two functions: elmpd-connect & elmpd-send. Each connection consumes a socket & optionally a callback-- that's it (no buffer, no txn queue). Put another way, if libmpdel is Gnus (featureful, encourages you to read your e-mail in a certain way), then mpdel is mailutils (small utilities that leave it up to the user to assemble them into something useful).

[DamienCassou]

Thank you for your detailed answer! Have fun with MPD.