This is a transport neutral client implementation of the STOMP protocol.
This is a python client implementation of the STOMP protocol.
The client is attempting to be transport layer neutral. This module provides functions to create and parse STOMP messages in a programmatic fashion. The messages can be easily generated and parsed, however its up to the user to do the sending and receiving.
I’ve looked at the stomp client by Jason R. Briggs. I’ve based some of the ‘function to message’ generation on how his client does it. The client can be found at the follow address however it isn’t a dependency.
In testing this library I run against ActiveMQ project. The server runs in java, however its fairly standalone and easy to set up. The projects page is here:
To see some basic code usage example see example/stomper_usage.py. The unit test tests/teststomper.py illustrates how to use all aspects of the code.
The example receiver.py and sender.py show how messages and generated and then transmitted using the twisted framework. Other frameworks could be used instead. The examples also demonstrate the state machine I used to determine a response to received messages.
I’ve also included stompbuffer-rx.py and stompbuffer-tx.py as examples of using the new stompbuffer module contributed by Ricky Iacovou.
This is the default version of the of STOMP used in stomper versions 0.3.x.
This is no longer the default protocol version. To use it you can import it as follows:
import stomper.stomp_10 as stomper
This is the default version used in stomper version 0.2.x.
Thanks to Ralph Bean (https://github.com/ralphbean) contributing a fix to setup.py and utf-8 encoding under python3.
Thanks to Lumír ‘Frenzy’ Balhar (https://github.com/frenzymadness) contributing python3 support.
This release makes STOMP v1.1 the default protocol. To stick with STOMP v1.0 you can continue to use stomper v0.2.9 or change the import in your code to:
import stomper.stomp_10 as stomper
Note Any fixes to STOMP v1.0 will only be applied to version >= 0.3.
Thanks to Ralph Bean for contributing the new protocol 1.1 support:
Thanks to Daniele Varrazzo for contributing the fixes:
I forgot to add a MANIFEST.in which makes sure README.md is present. Without this pip install fails: https://github.com/oisinmulvihill/stomper/issues/3. Thanks to Ian Weller for noticing this. I’ve also added in the fix suggested by Arfrever https://github.com/oisinmulvihill/stomper/issues/1.
Add contributed fixes from Simon Chopin. He corrected many spelling mistakes throughout the code base. I’ve also made the README.md the main
Add the contributed fix for issue #14 by Niki Pore. The issue was reported by Roger Hoover. This removes the extra line ending which can cause problems.
OM: A minor release fixing the problem whereby uuid would be installed on python2.5+. It is not needed after python2.4 as it comes with python. Arfrever Frehtes Taifersar Arahesis contributed the fix for this.
OM: I’ve fixed issue #9 with the example code. All messages are sent and received correctly.
This release integrates the bug fixes and the optional stompbuffer contributed by Ricky Iacovou:
http://stomp.codehaus.org/Protocol gives the example:
CONNECT login: <username> passcode:<passcode> ^@
and comments, “the body is empty in this case”. This gives the impression that the body is exactly defined as “the bytes, if any, between the ‘nn’ at the end of the header and the null byte”.
This works for both binary and ASCII payloads: if I want to send a string without a newline, I should be able to, in which case the body should look like:
this is a string without a newline^@
… and the receiver should deal with this.
This impression is reinforced by the fact that ActiveMQ will complain if you supply a content-length header with any other byte count than that described above.
I am also unsure about the newline after the null byte as nothing in the protocol says that there should be a newline after the null byte. Much of the code in StompBuffer actively expects it to be there, but I suspect that relying on a frame ending ‘x00n’ may well limit compatibility. It’s not an issue with Stomper-to-Stomper communication, of course, as the sender puts it, the receiver accepts it, and ActiveMQ happily sends it along.