On 2008/11/21 22:35, Marc Pavot <[EMAIL PROTECTED]> wrote:
> > 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...
>
> I attach a separate patch. What would be the advantage of this
> timeout thing? I don't see in which use case it can be useful.
Thanks, I have merged your patch. Please write a patch which adds
documentation for that feature to doc/protocol.xml.
Providing a timeout would allow the client to let MPD do the timing,
this way simple clients could just read() from the MPD socket, without
going through the hassle of select()/poll(), and still do regular
checks. Maybe useful for a scrobbling client which want to submit the
current song after it has been playing for a minute or so... I don't
consider this feature too important, and it is difficult to implement
until MPD uses the GLib main loop (not before 0.14).
> > > - 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.
>
> Could you list these disadvantages? In fact I don't see any....
Not leaving idle mode does only work for events which provide all
information about the change to the idle response, like your mixer
response - it sounds obvious that we can just send the new mixer
value, and the client doesn't have to restart idle then.
Most (all?) events are more complex, and after each non-trivial event,
the client has to quit idle mode ("noidle"), query the new changed
subsystem ("plchanges", "status", ...), and re-enter idle mode
("idle"). This adds the overhead of having to quit idle mode. I
assume that the client wants to leave idle mode anyway, so I've made
it the default.
Another disadvantage: with your idea, MPD would have to send _every_
micro event to the client. Say the volume was set from 90 to 91 to 92
.... to 100, that would result in 10 events. With MPD always leaving
idle mode, the client can decide how often it wants to receive events,
and thus MPD is able to bundle them (send only 1 mixer event instead
of 10).
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
