Roeland Douma wrote: > Hi, > > As my first (non-introduction) post I would like to talk about the MPD- > protocol. The whole protocol feels to me like it is just implemented when new > functionality was added to MPD. While I totally understand this from a > developers point of view. This is not a good thing. The protocol is the only > way to communicate with MPD so this should be very well structured. > > 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. > > However I think my point is clear. When looking at a random command it is not > clear (by the name) what is has effect on.
Agree here, but "fixing" this will mean breaking clients. > > Now I think the protocol would be a lot more efficient if it was event based > (or even better publish-subscribe) but since cirrus has just added that a > couple of weeks ago I first want to see how it works before I start > criticising it. However I already do have some idea's. But more on that in > another thread. > > 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. Now if I understand it correctly events are > generated with cirrus's events so you should be notified by that in order to > update it all. This has been added by cirrus to the api. listplaylists > > 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. Is this really a huge problem? you just do the search for the album, and what you get back you add again. I agree it is not perfect, but works fine. Maybe a command that tells mpd to add the result of the next search/find query (instead of returning to client)? > > 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. > I had this problem too. I solved this for the "Play queue" by doing a lazy view. I only retrieve the songs from the queue that are visible. If this is also possible for f.e. playlist content it could reduce a lot of (instant) traffic. > I have some other ideas but they are more related to features of MPD instead > of the protocol. So an other time for that. > > Note that it is not my intention to start a flame war. Anyway I would love > to get input/opinions on all of this. > > Greetings, > --Roeland Q > > ------------------------------------------------------------------------- > 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
