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=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
