hi, totally different take on this... We could talk about the merits of various protocols (I see fedmsg uses ZeroMQ) but that is a deep rabbit hole... to me, fedmsg looks like it is making a ZeroMQ version of a broker (which is a bit ironic given the original point of that protocol) trying to build a broker ecosystem is hard. Using an existing one is much easier. so to me it makes sense that fedmsg is not really working out.
However, <for what it is worth> I work in telecom for meteorology, and we ended up with a general method for file copying (catchphrase: rsync on steroids*.) ( *every catchphrase is a distortion, no dis to rsync, but in certain cases we do work much faster, it just communicates the idea.) Sarracenia ( https://github.com/MetPX/Sarracenia) is a GPL2 app (Python and C implementations) that use mozilla public license rabbitmq broker, as well as openssh and/or any web server to do fastish file synching, and/or processing/orchestration. The app is just json messages with file metadata sent through the broker. Then you daisy chain brokers through clients. No centralization (every entity installs their own broker), No federated identity required (authentication is to each broker, but they can pass files/messages to each other.) A firstish thing to do with it would be to sync the debian mirrors in real-time rather than periodically. Each mirror has a broker, they get advertisements (AMQP messages containing JSON file metadata) download the corresponding file, and re-advertise (publish on the local broker with the local file URL) for downstream clients. You can then make a mesh of mirrors, where, if each mirror is subscribed to at least two others, then it can withstand the failure of any node. If you add more connections, you increase redundancy. Once you have that sort of anchor tenant for an AMQP message bus, people might want to use it to provide other forms of automation, but way quicker and in some ways much simpler than SMTP. but yeah... SMTP is a lot more well-known/common. RabbitMQ is the industry dominant open solution for AMQP brokers. sounds like marketing bs, but if you look around it is what the vast majority are using, and there are thousands upon thousands of deployments. It's a much more viable starting point, for stability, and a lot less assembly required to get something going. Sarracenia makes it a bit easier again, but messages are kind of alien and different, so it takes a while to get used to them. </for what it is worth> On Sun, Mar 22, 2020 at 8:24 AM clime <cli...@gmail.com> wrote: > Hello! > > Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html - > fedmsg usage in Debian. > > There is a note: "it seems that people actually like parsing emails" > > What about adding email backend to fedmsg then. Wouldn't it be an > interesting idea? It could basically rely on postfix for sending > messages, hence providing decentralization as well as high > reliability. I think that amount of events that happen in distribution > (like package update, package build) is never so huge that email > infrastructure wouldn't handle it and also the machine mailing > infrastructure could be optionally be separated from the human one if > needed. > > So fedmsg would become a tiny wrapper over email that would just > serialize and parse json data to and from email messages and check > signatures. > > I am asking because I like the idea of distribution-independent > infrastructure message bus that this project had. > > Btw. instead of json, yaml could be used so it is nicer to human eyes. > > clime > >
