Quoting Daniel Pocock (2013-04-25 17:34:03) > ZeroMQ is a very lightweight solution - it is brokerless (like > multicast) so won't necessarily support the requirement for durable > subscriptions (keeping messages queued up for clients that are disconnected) > http://www.zeromq.org/topics:requirements-for-reliability As I mentionned in my original email (granted, without expanding much on it), I plan to implement a mechanism to solve this very problem by keeping the messages sent on the emitter side and resending them on demand. > Some things that are worth looking at: > > - do we want to use an AMQP broker? In theory, this is an open standard > like SMTP: the clients and brokers are interchangeable This solution has been already examined by the Fedora folks, and rejected by lack of scalability WRT the broker. This sort of question is actually why I think it is a good idea to use fedmsg because its authors have needs that are quite similar to ours, and virtually the same use cases. > - as an alternative, could we use something like SIP or XMPP as a > messaging platform? Then people can receive messages in their chat > client. In this case it doesn't appear to be the optimal solution, but > these protocols are quite good for systems that are very widely > distributed over public networks. Correct me if I'm wrong, but isn't SIP specific to VoIP? I don't know much about XMPP outside of its application in chatting. > - then again, there are plenty of examples of systems like Apache Camel > that can take a message from a traditional broker and deliver it to just > about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200 > other possible destinations: > http://camel.apache.org/components.html > and it can use Java or XML to describe various filters and transforms See above. Cheers, Simon
Attachment:
signature.asc
Description: signature