change the name so it doesn't contain 'fedora-' prefix

[praiskup]

I'm just curious whether the "fedora" prefix is needed; there are some concepts (at least the schema/validators) that would be useful to use on different message buses as well, other than the fedora's AMQP....

When I'm writing this, I have in mind the Red Hat internal stomp bus.... we have some basic support of that bus in copr sources, and we have to support this in future definitely.... Now consider some copr message consumers want to consume both Fedora Copr and Red Hat Internal Copr (there are such consumers), but they want to work with Copr messages consisntently.... so I'll try to make the support so the schemas work on both places.

Also note that historically fedmsg was from "Fedora" word, and later it changed to "federated". :-)

[praiskup]

Don't take this too seriously, but rather like a question: Is fedora-messaging code meant to be general enough to use it for working with other buses? If there's negative answer, it should be documented. Otherwise explicit saying "feel free to use this for working with other buses" would be nice as well. If the name of project is unfortunate, it's better to rename rather sooner than later.

[jeremycline]

The vast majority of the code here is just a wrapper around pika with some additional opinions specific to Fedora (certain message formats, for example). It'll obviously work with any RabbitMQ instance someone sets up as long as they have the same opinions we currently have, but it doesn't try to be a generic library that, say, crosses protocols (it even expects a couple RabbitMQ extensions to AMQP 0.9.1). The "fedora-" prefix is there to signal that it's really a collection of Fedora's messaging opinions.

The Red Hat internal message broker does not, from what I understand, support AMQP 0.9.1. #148 was filed after we had a talk how to share between Fedora and Red Hat. If Red Hat wrote its own consume loop using an AMQP 1.0 library, but offered the same consumer API - a callback function with the same signature, handling exceptions the same way, etc - consumers could easily be shared back and forth. Since this is Python, you could even do horrible things and have the Red Hat package monkey-patch a bunch of stuff to make the fedora_messaging.api.* functions work. As far as I know no one is working on that internally at the moment. Or if they are, I've not heard from them.

I'm personally not interested in renaming the project. Red Hat has an odd love of renaming tools they use internally, but I think that's silly and no one should care if the word "fedora" shows up in a package they use for internal work. Outside of Fedora and Red Hat, though, I don't think anyone should be interested in this project. If there is* interest in some general feature here it should be pushed into upstream pika or jsonschema or out into a generic package.

* What I mean is that I don't think the reward is worth the pain, but if I felt no pain I don't care what it's called.

[praiskup]

After some time, thinking again about this.

There are several things fedora-messaging does:

1. It abstracts publishing/consuming the messages to/from AMQP
2. It does the "entrypoint" <-> "class" mapping
3. Validates messages according to their schema

The fact it does so much really, really complicates use of the fedora-messaging code when we in advance expect to use the schema defined messages on multiple bus types.

2 and 3 is (could be) bus-type agnostic because we just somehow bake the entrypoint string an automatic way into the send message, and than on consumer side we automatically instantiate proper message object form class given by that info.

If not completely separated, we should have a way to let other buses do the "entrypoint to message class" mapping easily. ATM we do:

def message_callback(message):
    do_something_useful_with(message)

api.consume(message_callback, bindings=bindings, queues=queues)

But other buses might need in general something like:

# the same concept of handling the messages
def message_callback(message):
    do_something_useful_with(message)

def raw_message_callback(raw_message):
    # Get the uniform format of message that consists of the
    # body_schema defined format + entry_point baked in.
    message = get_defined_message_by_schema(raw_message)

    # get an object of the concrete message class
    message = reinstantiate(message)

some_form_of_cosume_method(callback=raw_message_callback, ...)

That said, it would be nice if we could split fedora-messaging somehow into two parts. One that

• strictly defines the way to specify messages (via classes, schemas, and the mapping from entrypoint --> reinstantiate mapping), and second

• which provides a connection to fedora-messaging AMQP bus

Internally we could mimic the methods from the second part for STOMP bus, and eventually we could think about some common class we could just inherit from.

[koobs]

FWIW, I looked at fedmsg when it was active and prior to its deprecation as an option for use in and for the FreeBSD project, to bring together all the various events and message formats that are generated in the same way Fedora had. It remained (remains?) the most obvious and shortlisted candidate, though when I saw the deprecation and new naming, I assumed that the project was heading in a more prescriptive and Fedora specific (less generic) direction.

I'd still love a library/framework to work with and on that could cater to the generic and common underlying problem space of unifying heterogenous events/messages/systems, and while I entirely understand that this was always designed to level Fedora up, it absolutely has (great IMO) value outside that context.