On 2008/11/14 10:50, Roeland Douma <[EMAIL PROTECTED]> wrote: > I understand that with the current design this makes everything more complex. > However what about adding another socket? For publish-subscribe or events? > Since right now I can think of some cases where things can go wrong.
You can already open another dedicated socket for "idle", but I discourage to do that, because it consumes precious resources. > Lets say I am running the idle command. So I receive events. Now > lets say I want to pause the current song. I then have to quit the > idle state. Send the pause command. And then call idle again. Now > lets say in the mean time an event has been send that (should) tell > me the play list is updated. I missed that. Tons of other examples > can be found. The "idle" command handles this in a safe manner: it manages an "idle_flags" bit set for every client (see src/client.c, struct client), and ORs each event into it, even if the client is not in "idle" mode. The next "idle" will return immediately, no event is lost. Yeah, this important detail is missing in the docs. 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
