Hi Roeland,
I'm happy that you are joining the discussion here. We have recently
been talking about better integration of MPD client developers into
the whole MPD project.
On 2008/11/13 21:28, Roeland Douma <[EMAIL PROTECTED]> wrote:
> Take for example the naming of the functions in the protocol. We
> have list, listinfo, listallinfo, lsinfo. All commands that look the
> same. But have different meanings. Now I could talk about the
> difference between them and how the naming is not consistent trough
> out the protocol. One example: list should be something like
> searchDatabase.
Right, the protocol has grown over the years, and some command names
aren't exactly self documenting. This is a little bit displeasing,
but I do not consider it a problem that must be fixed. As Qball said,
we need to keep compatibility, and since command names are only
visible to the client library, this affects only little code.
What should definitely be improved is the documentation. I will
convert doc/COMMANDS to docbook, and after that, we should work on
extending it. Maybe somebody helps me with merging information from
the wiki.
> Other than that there is no command now for retrieving all the play
> lists from the server. lsinfo works. But that would mean I have to
> parse that again. This is a missing feature. Since it means parsing
> all stuff from lsinfo (which could be a lot!) every time.
Has been implemented 3 weeks ago.
> Other than that right now adding songs is a real pain in the ass. Or
> to be more precise adding albums. When I supply the artist and the
> album MPD should be able to add this album by itself right? Same for
> everything from a specific artist. I do realise this function can't
> be always used when people have a lot of duplicated songs or an
> album double in their database. But in the general case this would
> be very use full.
Maybe some command "searchadd" which adds all search results to the
playlist? This would be trivial to implement. Care to write a patch?
> Now this is not really part of the protocol but still related to it.
> Compression. Why do we send everything in plain text? It is true
> that most commands are very small. But for example retrieving the
> play list over at my folks is 4.5 MB. While when it is gzipped it is
> only 630 kb. This can save a lot of network traffic.
Why not. Command "startzip" (similar to SMTP's "starttls") wraps the
whole communication channel in zlib, if the server supports it. From
there, supporting SSL would be another small step ("starttls").
On the other hand, zlib compression should probbly only be applied to
some responses, since it only adds overhead for 99% of the commands.
I'm not sure yet.
> I have some other ideas but they are more related to features of MPD
> instead of the protocol. So an other time for that.
We have already lots of ideas for post-0.14 development, the more the
better. Let's talk about yours.
Max
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
