On 25/04/13 13:50, Simon Chopin wrote: > Hi, > > Nicolas Dandrimont and I are currently working on a project proposal for > the Google Summer of Code to use the messaging system written by Fedora, > fedmsg[0][1], within the Debian infrastructure (some of you might have seen > the various ITPs related to that on -devel). > > Tollef kindly pointed out to us that Debian service administrators would > probably have something to say about all this, so here we are. > > As a premise, please note that we obviously plan to make fedmsg > distro-agnostic before anything else (than packaging). The original > upstream author seems very enthousiastic about the project, which makes > it probable that we won't have to carry those patches on our own. > > The thing itself is based on the ZeroMQ protocol. > > To quote Nicolas: >> One of the key outcomes of getting such a system in place, is that everyone, >> everywhere, can start listening to the messages and using them, opening up >> lots >> of doors for people to make amazing services based on Debian. >> >> A few ideas: >> - getting a signal from the archive on an accepted package (I'm confusing >> binaries and sources for the sake of brevity): >> → Trigger a piuparts run >> → Trigger lintian checks >> → Let any derivative intent a rebuild >> → Signal ports to rebuild >> → Trigger a jenkins job on specific package uploads >> → Post to pump.io/identi.ca/twitter >> → get a notification on your desktop >> → ... >> - one of your pet packages gets a git commit >> → try a rebuild >> → run QA checks >> → ... >> >> (boy, that escalated quickly) >> >> I think the possibilities are quite nice, and, as the fedmsg webpage says, >> that >> "gives new meaning to open infrastructure". > Two features I'd like to implement during this GSoC that are not AFAICT > already present in fedmsg are GPG support and some kind of playback > mechanism for the systems where it is important that all messages are > sent and received (there are some others where the information would > have value only at the time of emitting, I suppose). > > 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 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51794ceb....@pocock.com.au
