On 2008/11/16 01:08, Marc Pavot <[EMAIL PROTECTED]> wrote:
> I propose you a patch that improves different aspects of idle
> command:
Hi Marc,
thanks for the patch, it's a useful contribution to the discussion. I
have request on the form you send patches: please don't mix two
or more different topics in one patch. Send one patch per change.
This way, it's easier to review it, and it's also easier to
cherry-pick one I like, and apply it earlier, while the other ones are
being discussed. Tools like stgit make that really easy.
> - It adds a new 'elapsed' event to notify clients when the elapsed time has
> changed (in absolute value in second)
We discussed that recently in IRC, and the conclusion was: we don't
need such an event, the client can just set his own timer, and
increase the elapsed time once per second without talking to the
server. Whenever another client seeks, it receives the "player"
event, and will retrieve the new position from the server. Since
clocks may vary, the client will also refresh the time after some
interval (maybe 30, maybe 60 seconds - not too important). It is
however required that the server checks if the song playback is
real-time, and if there are random skips (faulty input file?), it will
tell the clients.
> - It adds the possibility to choose which notification you want to receive.
> The idle command can now take no argument (same behavior as before) or
> several arguments.
> For example if a client uses command 'idle mixer elapsed', it will only
> receive notifications when the volume changed or when the elapsed time
> changed.
Good idea.
Someone proposed that "idle 10" would make MPD respond after 10
seconds, disregarding whether an event has really happened, and
probably returns with an empty event set.
Can you make a separate patch of that? And maybe implement the
timeout thing if you have time...
> - And last, with this patch MPD doesn't leave idle mode anymore when a
> notification has been done. It means that idle mode will continue until
> 'noidle' command is sent. I think this will easy client implementation of
> idle command and reduce a lot the amount of useless traffic. Please tell me
> if you see a major drawback with this behavior.
No, I think the disadvantages of this solution will prevail here.
Events aren't that often (unless we really implement your 'elapsed'
event), and after most events, the client has to query the server
anyway.
On 2008/11/16 12:24, Marc Pavot <[EMAIL PROTECTED]> wrote:
> This new patch replaces the previous one. It adds the possibility to
> send the new value in a notification.
>
> For example, if the volume changes to 85, MPD sends 'changed: mixer
> 85'.
While this may reduce the number of times you have to abort idle after
an event, I'm against it. The mixer example is really trivial, but
most events change stuff which just can't be expressed in one single
line. Of course, we could design more protocol extensions for all
that, but I suggest we don't make this idle protocol more complex, and
in the end nobody understands how to use it.
> + /* No argument means that the client wants to receive everything */
> + if (flags == 0) {
> + for (j = 0; idle_names[j]; ++j) {
> + flags |= (1 << j);
> + }
> + }
flags = ~0;
;-)
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
