The code for the experimental STOMP adapter for RabbitMQ is distributed separately from the main server, at the moment. This post walks through the steps needed to try the adapter out, running it against a recent snapshot release of RabbitMQ. The perl Net::Stomp STOMP client is used to demonstrate the adapter in action, subscribing to a queue and sending a couple of messages to it.
Continue Reading 7 comments February 2nd, 2008 tonyg
We’ve just finished and released our .NET/C# client library for AMQP. We developed it on Mono, and made sure it ran on the Microsoft .NET stacks as well - versions 1.1 and 2.0. There’s also a WCF binding, for exposing WCF-based services over AMQP. (The WCF binding only compiles and runs on the Microsoft CLR implementations, until Mono’s Olive WCF implementation matures a little, anyway.)
One interesting thing about the library is its support for more than just one protocol variant: it speaks AMQP 0-8 as standardised, AMQP 0-8 as extended by QPid, and AMQP 0-9 as standardised (sans the bits of the spec marked “work in progress”, ie. the Message class). You can switch protocol variants at runtime, and there’s a common interface that abstracts away from the incompatibilities in the protocol variants. We’ve run the library against RabbitMQ (of course), as well as QPid-java and OpenAMQ 1.2c4.
The library is documented in a PDF user guide, which actually contains quite a bit of useful general AMQP information and guidelines, and could form the core of a language-neutral RabbitMQ manual. The detailed API guide is also available - you can download the code, the binaries, and all the different reformattings of the documentation on the interim page for the .NET/C# client library.
Our RabbitMQ website is starting to look a bit messy, so we’re working on a revised layout that should be a bit tidier; then, the .NET stuff will be presented alongside all the other client libraries and bindings we have available, rather than being presented as a separate-looking piece.
4 comments January 30th, 2008 tonyg
Thanks to a comment from Claus, I’ve discovered the wonderful fact that null is not permitted as a key in an IDictionary in .NET. As it happens, the main problem was that I’d not covered namespaceless classes in NDocProc at all gracefully, but nonetheless, forbidding nulls as dictionary keys is a strange design decision.
I’ve fixed the bug, and now NDocProc handles types with no namespace much more gracefully. I’ve updated the darcs repository:
darcs get http://www.lshift.net/~tonyg/ndocproc/
and there’s a snapshot (source and binary) available, as well: ndocproc-200801211208.zip
Add comment January 21st, 2008 tonyg
A couple of months ago, I improved our erlang SMTP server code.
Mon Oct 15: Support callbacks and more of the spec.
Support multiple forward paths. Support callbacks for verification and delivery. Pass domain as well as mailbox for reverse and forward paths. Cope with improper line termination. Log failures in delivery/verification callbacks.
Wed Oct 17: Split out smtp_util:strip_crlf; be RFC2821-strict about CRLF
The code is available by browsing or through darcs:
darcs get http://www.lshift.net/~tonyg/erlang-smtp/
1 comment December 28th, 2007 tonyg
Sam Ruby examines support for astral-plane characters in various JSON implementations. His post prompted me to check my Erlang implementation of rfc4627. I found that for astral plane characters in utf-8, utf-16, or utf-32, everything worked properly, but the RFC4627-mandated surrogate-pair “\uXXXX” encodings broke. A few minutes hacking later, and:
Eshell V5.5.5 (abort with ^G)
1> {ok, Utf8Encoded, []} =
rfc4627:decode("\"\\u007a\\u6c34\\ud834\\udd1e\"").
{ok,<<122,230,176,180,240,157,132,158>>,[]}
2> xmerl_ucs:from_utf8(Utf8Encoded).
[122,27700,119070]
3> rfc4627:encode(Utf8Encoded).
[34,122,230,176,180,240,157,132,158,34]
4>
Much better.
You can get the updated code using mercurial:
hg clone http://hg.opensource.lshift.net/erlang-rfc4627/
Add comment November 16th, 2007 tonyg
NDocProc, our small and simple .NET javadoc-like documentation generator, has been updated for C# 2.0 and Generics.
Changes since the previous announcement include:
The project homepage is here. You can download a zip of the latest version, or use darcs to check out the repository:
darcs get http://www.lshift.net/~tonyg/ndocproc/
5 comments November 7th, 2007 tonyg
A couple of weeks ago, Richard W. M. Jones released JONESFORTH, which I thought was pretty exciting. Today I spent a few hours porting the assembly-language part to PowerPC on Mac OS X 10.3.9. It ended up being 600 non-comment lines of code in total, and took me about eleven hours in total to write and debug. It runs the standard JONESFORTH prelude, up to and including SEE.
You can download the code here: ppcforth.S.m4.
(It’s also available via darcs: darcs get http://www.eighty-twenty.org/~tonyg/Darcs/jonesforth.)
The assembler-macro tricks that the original i386 version uses are sadly unavailable with the default OS X assembler, so I’ve had to resort to using m4 instead; other than that, it’s more-or-less a direct translation of Richard’s original program. To compile it,
m4 ppcforth.S.m4 > ppcforth.S gcc -nostdlib -o ppcforth ppcforth.S rm ppcforth.S
To run it, download the JONESFORTH prelude (save it as jonesforth.f), and
$ cat jonesforth.f - | ./ppcforth JONESFORTH VERSION 14641 OK
Here’s an example session, decompiling the “ELSE” word:
SEE ELSE : ELSE IMMEDIATE ‘ BRANCH , HERE @ 0 , SWAP DUP HERE @ SWAP - SWAP ! ;
I’d like to thank Richard for such an amazingly well-written program: not only is JONESFORTH itself a beautiful piece of software, it’s also an incredibly lucid essay that does a wonderful job of introducing the reader to the concepts and techniques involved in implementing a FORTH.
2 comments October 4th, 2007 tonyg
In a previous post I explored some of the options for supporting RFC4627 (JSON) Unicode-in-strings well when mapping to Erlang terms. In the end, I settled on keeping the interface almost unchanged: the only change is that binaries returned from rfc4627:decode are to be interpreted as UTF-8 encoded text now, whereas before their interpretation was less well defined.
The new module is Erlang-RFC4627 version 1.1.0, and is available as a tarball, a debian package, or by browsing online here. You can also get the code using mercurial:
hg clone http://hg.opensource.lshift.net/erlang-rfc4627/
Here are some examples using the new module. First, let’s explore the autodetection of which encoding is being used. In the following example, we see UTF-16, both big- and little-endian, as well as ill-formed and well-formed examples of UTF-8 being passed through the autodetector. (It also supports UTF-32 big- and little-endian.)
Eshell V5.5.5 (abort with ^G)
1> rfc4627:unicode_decode([34,0,228,0,34,0]).
{'utf-16le',"\"ä\""}
2> rfc4627:unicode_decode([0,34,0,228,0,34]).
{'utf-16be',"\"ä\""}
3> rfc4627:unicode_decode([34,228,34]).
** exited: {ucs,{bad_utf8_character_code}} **
4> rfc4627:unicode_decode([34,195,164,34]).
{'utf-8',"\"ä\""}
5>
Now let’s look at decoding some UTF-8 encoded JSON text into Erlang terms, and vice versa.
5> rfc4627:decode([34,194,128,34]).
{ok,<<194,128>>,[]}
6> rfc4627:encode(<<194,128>>).
[34,194,128,34]
7> rfc4627:encode_noauto(<<194,128>>).
[34,128,34]
8> rfc4627:unicode_encode({’utf-32le’,
rfc4627:encode_noauto(<<194,128>>)}).
[34,0,0,0,128,0,0,0,34,0,0,0]
9> rfc4627:encode_noauto({obj, [{[27700], 123}]}).
[123,34,27700,34,58,49,50,51,125]
10> rfc4627:encode({obj, [{[27700], 123}]}).
“{\”æ°´\”:123}”
11>
Notice, on that final example, that Erlang is printing the final UTF-8 encoded JSON text as if it were Latin-1. This is nothing to worry about: the numbers in the returned list/string are the correct UTF-8 encoding for Unicode code point 27700.
2 comments October 3rd, 2007 tonyg
Some seven months ago, I built simple Erlang modules for generic SMTP and POP3 services. The idea is that the programmer should instantiate a service, providing callbacks for user authentication and for service-specific operations like handling deliveries, and scanning and locking mailboxes. Originally, I was planning on providing SMTP-to-AMQP and AMQP-to-POP3 gateways as part of RabbitMQ, but I haven’t had the time to seriously pursue this yet.
A snapshot of the code is available as a zip file, or you can browse the code online or retrieve it using darcs:
darcs get http://www.lshift.net/~tonyg/erlang-smtp/
The current status of the code is:
io:format, and the POP3 mailbox and user authentication database are similarly hard-coded.
Patches, bugfixes, contributions, comments and feedback are all very welcome!
Update: a new post summarises changes since this post, including pluggable callbacks etc.
Add comment September 20th, 2007 tonyg
There are a few tools for building javadoc-like documentation for .NET code available out there on the ‘net. Unfortunately, the major contenders (e.g. NDoc, Sandcastle) suffer from a few flaws: they are variously not free (gratis), not free (libre), not cross-platform, not maintained, and/or not easy-to-use. Therefore:
Presenting: NDocProc.
Download a zip snapshot from here, or use darcs to check out the repository:
darcs get http://www.lshift.net/~tonyg/ndocproc/
Update: New release available.
Add comment September 13th, 2007 tonyg
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Sep | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||