On 7 February 2011 20:12, mike castleman <span dir="ltr"><<a href="mailto:m@mlcastle.net">m@mlcastle.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If my experiments are successful (or fail in interesting ways), I'll try<br>
to write up a blog post with my findings. Certainly the RabbitMQ C<br>
library does not currently suffer from an excess of documentation.<br></blockquote><div><br>Great! Please do! You're quite right about the lack of documentation - entirely my fault :-)<br>�</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As far as I can tell, rais is (the beginning of) an AMQP broker<br>
implementation in C? Is that correct?<br></blockquote><div><br>Hm, sort of. It's an experiment probably not worth continuing with. Both librabbitmq's clunkiness and some misdesign entirely blamable on rais itself led to it being more trouble than it was worth. The idea was to have a little local relay node on a client machine that would provide a staging area for messages on their way in and out - a kind of responsibility store, if you like, that would give "reliable/at-most-once" delivery and deduplication semantics on top of a remote RabbitMQ. It turned out that programming in C in that style was a royal pain in the behind. Much better to use ucontext_t or other approaches.<br>
<br>Regards,<br>� Tony<br><br></div></div>