PROPOSAL: XMPP as a broker backend

[phdavis1027]

Checklist

• I have checked the issues list
  for similar or identical feature requests.
• I have checked the pull requests list
  for existing proposed implementations of this feature.
• I have checked the commit log
  to find out if the same feature was already implemented in the
  main branch.
• I have included all related issues and possible duplicate issues
  in this issue (If there are none, check this box anyway).

Related Issues and Possible Duplicates

None found

Related Issues

None found

Possible Duplicates

None found

Brief Summary

I want to add XMPP with pub/sub as a brokering backend. The work I do with my co-op involves a lot of XMPP knowledge and infrastructure, I have vague future plans kicking around for an app that uses celery for long-running NLP tasks and would like to use XMPP for remote task execution, and, frankly, adding this feature just sounds fun.

Design

Architectural Considerations

From my perusal of the codebase, it seems like most of the protocol logic would live in Kombu. slixmpp would be the client impl. Finally, my vision is that any server that supports the pubsub XEP should just work. This includes Prosody and potentially ejabberd, depending on whether message bodies are required.

Proposed Behavior

Brokers would do at least as much as they do now. No breaking changes or new functionality envisioned at this time.

Proposed UI/UX

The URI to a particular XMPP broker would be specified using the XMPP pubsub URI scheme. In practice, this probably means something like: xmpp.pubsub:pubsub.shakespeare.lit/princely_musings/ (see 'A URI referring to a node' in that URI XEP). Additionally, XMPP clients such as Cheogram and Gajim allow for "Advanced Connection Settings," i.e., specifying a host and port other than the one co-identified by the jid of the URI. This can be an additional, optional kwarg, and is useful for things like debugging on local instances. Additionally, celery will need a jid + credentials to publish messages from the configured pubsub service (for the producer), as well as a jid from which to subscribe (for the consumer). These can be the same.

Diagrams

None relevant, although again it seems that most of the implementation would be in a new Transport within the Kombu repo.

Alternatives

None relevant

[lukal-x]

👀

This is interesting. I'm currently exploring what kind of things can be done with just BOSH and I'm thinking a celery-like proof of concept can be built off of BOSH, as a reference perhaps.

Will report back here if I come up with something.

[auvipy]

is it really that useful protocol?