Hi, 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.
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. But it all comes down to some kind of race conditions. A separated socket to listen on will be better. That way you can just keep listing on that socket and it will act like some kind of interrupt channel. The current socket (the one implemented right now) can be used as a control channel. --Roeland On Friday 14 November 2008 09:01:53 Max Kellermann wrote: > On 2008/11/13 21:45, Marc Pavot <[EMAIL PROTECTED]> wrote: > > As already proposed by someone else, a publish-subscribe protocol would be > > much more appropriate because with the 'idle' approach: > > - you have to send 'noidle' command each time you want to send another > > command > > - you have to send 'idle' again after this command > > - you have to send 'idle' again each time a notification has been done > > The advantage of my 'idle' design is that the client declares when it > is willing to receive notifications. No event parsing right in the > middle of another response, because this makes the protocol ugly and > the protocol parser complex. > > Sure, you have to send some more commands, but since you can do > pipelining, this is very little overhead. This overhead is only > present when the client really wants to send a command. Clients who > properly use 'idle' will seldomly have send any command at all. > > > - you cannot subscribe to receive only some of the notifications > > Sounds like a reasonable feature request. What about "idle mixer > options" to only receive "mixer" and "options" events? Other ideas? > > > > I could really need a helping hand on libmpdclient. Are you familiar > > > with asynchronous I/O? > > > > I am not an expert of asynchronous I/O but it may be time to become one > > :-). > > Hey, that's the perfect attitude towards programming problems! :-) > Coding async I/O is challenging, but also a lot of fun. > > I hope I can count on you when I start the project "libmpdclient2". > > 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 > ------------------------------------------------------------------------- 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
