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
