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