Sorry for taking so long to reply, kinda busy. Here are the key points why I think "my solution" is superior, ordered from least to most important:
no limit to 255 songs - okay, it’s not probable anybody would get annoyed by this no incompatibilities between different clients: right now, each client has to choose how to distribute properties when playing songs next. If clients are not written with the possibility in mind that other clients may handle the priorities slightly differently, this may lead to incompatibilities making the user-experience very bad much much easier for client developers to implement: Right now, it is not a trivial task to add "play next" functionality to a client (only talking about the logic, not the ui). The developer needs to manage the priorities keeping track of the playback state etc. With my solution, enqueueing a song would be as simple as calling one command. I think this is a very important feature. Many music players are advertising this kind of functionality as major feature. As such, i think that it is very important to make it as easy as possible for client developers to implement this in a good and compatible manner. Regarding the compatibility issue: I think it should be possible (and not too difficult) to implement a compatibility mode which internally uses the new queue system but makes it possible to query and manipulate priorities which are internally translated from and into positions in the queue. Lukas > On 06 Jan 2014, at 07:59, Max Kellermann <m...@duempel.org> wrote: > >> On 2014/01/06 05:40, Lukas Stabe <lu...@stabe.de> wrote: >> My suggestion is to add an additional list of tracks to be played next. For >> lack of a better name >> i?ll call it the ?queue? (although it is not a queue in the strict sense, >> items could be reordered etc). >> >> When mpd finishes playing a song and the number of tracks in the queue is >> not zero, it plays the >> first song in the queue and removes it from the queue. When there are no >> tracks left in the queue, >> mpd resumes playing the playlist where it left of. > > This has been suggested over and over for many years before we had the > "priority" system. > > But what you describe exists already in MPD: call it "queue" or > "playlist", MPD has it already, and it is what decides what wil be > played next, just as you described. > > What you did not describe is why your idea is superior or even > necessary. So far, I cannot see anything that would be possible with > your system that is not already possible now. OK, queue longer than > 255 - 255 was an arbitrary limit, and nobody has ever requested to > enlarge it in the whole time this feature existed. > > On the other hand, your idea requires massive protocol extensions. > All commands that handle the "old-style queue" will need counterparts > to manipulate and query the "new-style queue". All clients need > special support for this, and until they have, they would not be able > to see the "new-style queue". And there are more interesting > compatibility problems: when MPD plays a song from the "new-style > queue", what song id will the "status" command print? > > Most client projects are not well-maintained (unfortunately), and > requiring all clients to be modified is just not a good idea. That > involve a lot of pain among users. A solution that does not involve > incomaptible protocol changes is favorable. And that was what I > implemented. > > Admittedly, the priority feature may appear "bolted on", and it is, > but there is nothing particularly wrong with it. It is a simple > concept that solved the problem without any incompatible protocol > changes. It just gave clients more control over the way MPD chooses > the next song, and nothing more. > > Max >
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
