list active subscribers on a channel

482 views
Skip to first unread message

robj

unread,
Mar 18, 2011, 1:52:41 AM3/18/11
to Faye users
Is there any way to do this currently ?

Thanks,
Rob

James Coglan

unread,
Mar 18, 2011, 8:16:40 AM3/18/11
to faye-...@googlegroups.com
On 18 March 2011 05:52, robj <robert....@gmail.com> wrote:
Is there any way to do this currently ?

Sorry to disappoint, but no. I have no plans to implement this either, because in most cases it turns out to be a code smell and there are better alternatives. Would like to know what problem you're trying to solve -- we might figure out something better with some more context.

You might be able to implement this as an extension by intercepting the /meta/subscribe channel, although I'm not sure you'll be able to get enough info about disconnected clients to do a fool-proof job of it.

alessio alex

unread,
Mar 18, 2011, 8:21:30 AM3/18/11
to faye-...@googlegroups.com
I was thinking of implementing something like this myself, for the Twitter-like chat examples. It would be nice to show all users connected, so one could know who's available to follow.

Couldn't we make the server send information about who's connected just like it send messages?

James Coglan

unread,
Mar 18, 2011, 8:33:29 AM3/18/11
to faye-...@googlegroups.com
On 18 March 2011 12:21, alessio alex <alessio...@gmail.com> wrote:
Couldn't we make the server send information about who's connected just like it send messages?

This has been discussed before:

My stock answer is: exposing lists of client IDs is not terribly useful, because they very often do not have a one-to-one correspondence with a domain object. For example, a user in a chat application will often make use of several Faye clients, either because they change pages or because the server is restarted and the clients all need to acquire fresh IDs.

You should figure out what makes sense for your application, and how you can model your solution by sending messages. Faye is just designed for dispatching messages, not for being an out-of-the-box solution for any particular application. Think of it just as a data transport, like HTTP, not as an application framework. You don't want to couple your app too tightly to the network technology you're using.
Reply all
Reply to author
Forward
0 new messages