Re: [Musicpd-dev-team] idle command
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=100url=/ ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] idle command
On 2008/11/14 11:15, Roeland Douma [EMAIL PROTECTED] wrote: Other than that I think an important event is missing. The event that notifies the user of the place the song is. Since If I start a client I want to know that. This can be very small messages. But they can be very use full. You mean which song is currently being played? That's the event player. Documentation incomplete again. This however would be better done with publish subscribe. Since some clients might or might not be interested. With the current implementation publish subscribe should just be which events you would like to receive and which not. Which is ore or less the general concept of publish subscribe of course. I have an example for you. Lets say I have a mobile MPD client on my phone. I want to display the current song, the next song. And some controls. Then I a not interested in any other events. See my previous response to Marc in this thread: On 2008/11/14 09:01, Max Kellermann [EMAIL PROTECTED] wrote: On 2008/11/13 21:45, Marc Pavot [EMAIL PROTECTED] wrote: - 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? 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=100url=/ ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] idle command
The two sockets solution is easy to implement and interesting but as Max sayed it soncumes precious ressources. We may have another solution (used for example by XMMS2): - Each query has an identifier - Each reply has the identifier corresponding to the query - Each subscription to an event notification also has an identifier - Each notification has the identifier corresponding to the subscription This means some important changes in MPD protocol but it has several advantages: - It uses only one socket - It is easy to implement on client side (you just have to keep a list of identifier to understand what you receive) - It enables you to implement synchronous and asynchronous calls to MPD on client side which is not an easy thing with current protocol. - It will be easy to implement a publish-subscribe solution for event notifications Marc 2008/11/14 Max Kellermann [EMAIL PROTECTED] On 2008/11/14 11:15, Roeland Douma [EMAIL PROTECTED] wrote: Other than that I think an important event is missing. The event that notifies the user of the place the song is. Since If I start a client I want to know that. This can be very small messages. But they can be very use full. You mean which song is currently being played? That's the event player. Documentation incomplete again. This however would be better done with publish subscribe. Since some clients might or might not be interested. With the current implementation publish subscribe should just be which events you would like to receive and which not. Which is ore or less the general concept of publish subscribe of course. I have an example for you. Lets say I have a mobile MPD client on my phone. I want to display the current song, the next song. And some controls. Then I a not interested in any other events. See my previous response to Marc in this thread: On 2008/11/14 09:01, Max Kellermann [EMAIL PROTECTED] wrote: On 2008/11/13 21:45, Marc Pavot [EMAIL PROTECTED] wrote: - 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? 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=100url=/ ___ 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=100url=/___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] idle command
On 2008/11/14 11:41, Marc Pavot [EMAIL PROTECTED] wrote: The two sockets solution is easy to implement and interesting but as Max sayed it soncumes precious ressources. We may have another solution (used for example by XMMS2): - Each query has an identifier - Each reply has the identifier corresponding to the query - Each subscription to an event notification also has an identifier - Each notification has the identifier corresponding to the subscription This means some important changes in MPD protocol but it has several advantages: - It uses only one socket No difference to idle. - It is easy to implement on client side (you just have to keep a list of identifier to understand what you receive) I would call that idea much more complicated, because: - you have to generate these identifiers - you have to remember them - you have to parse them - you must always be prepared to receive an event, even when you're expecting a response to another command; don't underestimate the complexity attached to that! idle, in contrast, lets the client decide when it's ready to check for events, i.e. always start idle before returning control to the main loop (libevent, select(), poll()), and don't care about events while you're busy with something. - It enables you to implement synchronous and asynchronous calls to MPD on client side which is not an easy thing with current protocol. Right, pipelined commands could be reordered by the server. That's indeed an advantage, but would require a lot of additional complexity on the server side. Since commands shouldn't be blocking (except idle), I don't think it's worth it. - It will be easy to implement a publish-subscribe solution for event notifications MPD has that already... 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=100url=/ ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] idle command
Hi Why not? The client can let the connection block until something happens, or it can abort idle as soon as he wishes to use the connection for something else. That is simple, but powerful. 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 - you cannot subscribe to receive only some of the notifications 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 :-). Marc - 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=100url=/___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] idle command
On 08/11/04 14:59 +0100, Max Kellermann wrote: As far as I understand, when you are in 'idle' mode, you are blocking until an event occurs (song change, volume change etc...). It doesn't look really usable in a graphical client. Why not? The client can let the connection block until something happens, or it can abort idle as soon as he wishes to use the connection for something else. That is simple, but powerful. Anyway if you need help to implement this feature, I could work on it. I could really need a helping hand on libmpdclient. Are you familiar with asynchronous I/O? where can we get some information on the idle command and its semantics? since i maintain the perl bindings, i'd like to support it. thanks, jérôme -- [EMAIL PROTECTED] - 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=100url=/ ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
