Google released Mercurial support sooner than expected, so the source code for stomp.py and clover is now accessible directly from those projects.

Browse the source for stomp.py here: http://code.google.com/p/stomppy/source/browse/

Browser the source for proton here: http://code.google.com/p/proton-te/source/browse/

If you’re a regular visitor, you may have noticed my rather ill-fated attempt (IMO) at using a magazine style theme on this site has now been replaced by… well… very little theme at all.

This is not the only change. After much internal cogitation, I’ve decided to dump the forum, and use Google Groups for further discussion on all my projects. Along with moving the hosting of those projects elsewhere. In short, this blog now becomes more of a blog. The distinction makes sense in my head anyway.

While the old forum messages can still be found here: http://www.briggs.net.nz/log/forum, check below for where you should submit comments from now on.

YAK for WordPress
The main project page will now be at WordPress: http://wordpress.org/extend/plugins/yak-for-wordpress/.
General discussion will now be held at: http://groups.google.com/group/yak-discuss.
Bug reports can be posted to: http://groups.google.com/group/yak-bugs.

stomp.py
The main project page is at Google Code: http://code.google.com/p/stomppy/.
The discussion group can be found here: http://groups.google.com/group/stomppy.

Proton Template Engine
The project page is at Google Code: http://code.google.com/p/proton-te/.

Snake Wrangling for Kids
The project page is still here: http://www.briggs.net.nz/log/writing/snake-wrangling-for-kids/.
The discussion group is here: http://groups.google.com/group/swfk

More to come…

The distribution file for the Python2 version of stomp.py has been fixed. I had a minor problem in my setup which meant only half the files were included — not particularly useful to anyone.

I’ve also updated the Python3 version to include optparse for handling arguments, the facility to specify a file of commands as both a runtime argument and from within the stomp.py console.

For example, you can now do something like:

python stomp/cli.py --file mycommands.txt

Which I think is pretty useful, at least. Feedback welcomed.

Join the forum discussion on this post - (1) Posts

A Python3-compatible release of stomp.py is now available, along with doxygen-generated docs (finally). I’ve done a reasonable amount of tidying up in the Py3k version, along with adding support for sending files from the command-line interface. There have been a few additional bug fixes in both Python2 and Python3 versions.

See the project page for more information. Any problems, as usual either email or (better yet) post in the discussion forum.

I’ve refactored stomp.py for the version 2.0 release (yes, I realise I’ve missed version 1.9, but who’s going to quibble over a minor…?).

As well as refactoring, I’ve added help to the command-line client, a facility for recording stats (messages sent/received), and the start of some unit tests.

The refactored version 2 is available in branch “experimental-r2″. Run hg update -C experimental-r2 after pulling the latest changes from the repo.

Let me know what you think.

I’ve finally added a new forum for Snake Wrangling for Kids (python programming book for kids), and another for stomp.py.

Neither pages were attracting a huge amount of comment traffic, but even the small number of comments was becoming unmanageable.

On the SWFK front, it looks like the French translation is approaching completion — the current draft looks brilliant (arguably better than the original). Michel has done an excellent job. This is the first translation, and I’m keen to see more…

Well I did say sort of.

Yet another version of stomp.py can be found below.

After some consideration, I thought better of the one-listener-per-subscription method, including instead, addlistener & dellistener methods in the Connection class — thus all listeners receive all subscription messages. Otherwise, the question becomes how to handle acknowledgements? Does the first listener subscribe-call set the acknowledgement? In which case, what if the initial subscriber sets ack: auto and latter subscribers want client? Too much complexity, and, at least to me, this way is cleaner (and by cleaner, I mean it’s easier to determine ‘functional responsibility’).

One problem this change has exposed, is a bug in unsubscribe. I don’t (yet) know if it’s a problem in my module, in activemq/stomp, or it’s just one of those you-shouldn’t-be-coding-so-late-in-the-evening issues that suddenly vanishes when you try it again the next day. But I’ve tried an unsubscribe in a direct telnet session and (annoyingly) still receive messages to that destination, so evidence begins to point toward other sources. I’ll investigate further…

UPDATE 06/12/05: confirmed on a separate machine (& instance of activemq) that unsubscribe doesn’t work as expected.

Read the rest of this entry »

Yet another update of my stomp module.

This ‘release‘ tidies the code up a bit, adds some documentation, and fixes the command-line test code.

To get help for the module:

import stomp
help(stomp)

You can run from the command line, to test with a simple client. For example:

$ python stomp.py localhost 62003

CONNECTED
session:ID:muttley-32792-1133582529150-3:0

CONNECTED
session:ID:muttley-32792-1133582529150-3:1

subscribe /queue/a
send /queue/a hello
MESSAGE
message-id:ID:muttley-32792-1133582529150-2:0
destination:/queue/a

hello

END@

Or use in another script:

import stomp

st = stomp.Connection('localhost', 62003, 'test', 'test')
st.send('/queue/b', 'test2')
st.send('/queue/a', 'test1')
st.disconnect()

UPDATE 04/12/2005: Minor bug fix, and changed the read method to buffer 1024 chars rather than read 1 by 1

Here is an update of the stomp module, adding support for transactions (begin, abort, commit and the transaction header on send).

I remain unconvinced that this is the right way to do things, but at it does seem to work at least. I’ll know for sure when I try it out in anger next week.

Footnote: the disconnect method sets the running variable to None (to break the loop in thread run()), and sends a disconnect command through each sock connection. Interestingly it worked last night, but this morning it hung the python vm with 100% cpu. Adding a socket close (which should’ve been there anyway) fixes the problem.