I'm in favor of scrapping the current protocol and redesigning from
the ground up with a 2.0 protocol that's separate from the current
protocol. publish:subscribe, compression, and encryption are all
decent candidates for a protocol version bump.
all I ask is that if you add SSL, please make sure you add client key
authentication and support for certificate revocation lists :)
On Thu, Nov 13, 2008 at 11:45 PM, Max Kellermann <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------------------------
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
