* Daniel Pocock <daniel@pocock.com.au> [2013-04-25 17:34:03 +0200]: > On 25/04/13 13:50, Simon Chopin wrote: > > [ description of the fedmsg project ] > > Questions, comments? > > 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 > > 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 As Simon already said, the Fedora people have tested this and rejected it because it didn't scale. > - 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. > > - 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 Those are interesting suggestions, I actually had a look at Camel when it was suggested to us on another thread, but we will keep going on with fedmsg. There are several reasons for doing so: - It is currently implemented in Fedora, on an infra that is different to ours but has similar components - This allows for tool interoperability between distros, and why not for inter-distro collaboration - It's python, which fits very well with most of our stack - Upstream has been super, super helpful so far, and I don't see this changing I wanted Simon to start this thread to gather ideas: I know some people, mostly in DSA, have thought about such a system for some time, so this was more of a heads-up than wanting to reconsider the project from scratch. It landed on -devel because, well, we couldn't find a more appropriate list :) To get back to your remark, it would definitely be possible to build a fedmsg-to-xmpp filtering bridge, if there is interest, but that's not really the scope of this GSoC project. Cheers, -- Nicolas Dandrimont BOFH excuse #124: user to computer ration too low.
Attachment:
signature.asc
Description: Digital signature