[rabbitmq-discuss] building chat
alexis.richardson at gmail.com
Fri Aug 7 11:31:05 BST 2009
That's right, the spec does not specify this. However presence turns
out to be very useful for all sorts of lifecycle management, so it's a
natural thing to look at in an implementation.
On Thu, Aug 6, 2009 at 9:57 PM, Paul Jones<pauljones23 at gmail.com> wrote:
> Hi Ben,
> It'll be a custom RabbitMQ module - as far as I've seen, the spec doesn't
> specify anything like this (though I could be completely wrong on that).
> On Thu, Aug 6, 2009 at 9:42 PM, Ben Browitt <ben.browitt at gmail.com> wrote:
>> That is interesting for two reasons. First because I might actually
>> understand a bit of AMQP and second
>> because you are addressing this issue.
>> Will it be part of the AMQP spec or a custom RabbitMQ module?
>> Maybe I can hack something until you'll release this functionality.
>> And yes, I'll be interested to know when it is available for early
>> On Thu, Aug 6, 2009 at 10:52 PM, Paul Jones <pauljones23 at gmail.com> wrote:
>>> Hi Ben,
>>> The model does certainly work best in situations where consumers and
>>> producers have little need to know of each other.
>>> We are, however, currently experimenting with some presence
>>> functionality. This was originally prototyped quite a while ago, and it is
>>> currently being reworked to be remove a number of issues that previously
>>> prevented it being made mainstream. This functionality creates an exchange
>>> that will receive information about when queues, exchanges and bindings are
>>> created and deleted - this may help in your case by letting you see when a
>>> user subscribes or unsubscribes from another user's exchange.
>>> It is still under fairly heavy development at the moment, but I can let
>>> you know when it reaches a state where it might be useful to look at.
>>> On Thu, Aug 6, 2009 at 3:32 PM, Ben Browitt <ben.browitt at gmail.com>
>>>> I'm trying to understand how AMQP and RabbitMQ works by building a
>>>> simple chat.
>>>> From reading the AMQP specs I get the impression that it's best usage is
>>>> when someone publish content to an exchange
>>>> and someone else bind his queue to this exchange to get updates. This
>>>> model works very well for publish-subscribe
>>>> and to finance systems but chat could be different. I read the xmpp
>>>> gateway docs and have some questions.
>>>> In a chat we want to be able to get presence from users on our
>>>> friend-list, send them messages
>>>> and send subscription request and messages to users not yet on our
>>>> One possibility is that each user will have an exchange and a queue with
>>>> binding to his own exchange.
>>>> When user1 wants to send a message to user2 he send it directly to the
>>>> exchange of user2.
>>>> There is a problem with presence updates. If user1 changes his presence,
>>>> he'll have to sends the update
>>>> to the exchange of all the users on his friend-list. With this design we
>>>> move the logic to the client rather then use the AMQP features.
>>>> Another option is that when a user logs in he'll create a binding to the
>>>> exchanges of all the users on his friend-list.
>>>> When user1 want to send a private message or a presence update to user2
>>>> he'll send it to his own exchange and it'll be directed to user2. The
>>>> problem with this design is that users without mutual presence subscription
>>>> can't send private message to each other and can't send subscription
>>>> Can you please share your thoughts on the two options and maybe other
>>>> design options?
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss