<div dir="ltr">Ben, Thanks.<br><br>Coincidentally, I did look into rabbit_exchange:route while waiting for your response. One (very very minor) thing that struck me on reading it was the use of regexp:split/2 to convert "a.dotted.topic.key" to ["a","dotted","topic","key"]. I wondered why the more efficient string:tokens/2 was not used. They do have different behavior in edge conditions (e.g. ".atopic") - was that the reason?<br>
<br>Anyway, besides that, for now I'll probably just go with a topic exchange, which seems to be the general purpose ancestor of all the others. I really do not want to add my code to the Rabbit server side and risk having merge difficulties when future releases arise...<br>
<br>Regards,<br>Edwin<br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 8:50 PM, Ben Hood <span dir="ltr"><<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edwin,<br>
<div class="Ih2E3d"><br>
On Mon, Oct 20, 2008 at 11:17 PM, Edwin Fine<br>
<<a href="mailto:rabbitmq-discuss_efine@usa.net">rabbitmq-discuss_efine@usa.net</a>> wrote:<br>
</div><div class="Ih2E3d">> Sorry if this is answered elsewhere (I did look), but how (in a nutshell)<br>
> would I implement my own custom exchange type?<br>
<br>
</div>1. The abridged version:<br>
<br>
If you look into at functions rabbit_exchange:route/2 and<br>
lookup_qpids:/1 in the same module on the 18776 branch, you might be<br>
able to follow how the generalized routing mechanism works. Basically<br>
you read the routing table for bindings to queue names that match your<br>
key, resolve their corresponding process ids and the rest is handled<br>
for you.<br>
<br>
2. The realistic version:<br>
<br>
Somehow you're going to have to make a routing decision, and this<br>
usually has something to do with bindings, although you could<br>
theoretically create some kind of foo exchange that just picks some<br>
queue names out of a hat. But if you need to do stateful routing,<br>
you're going to have to retrieve the state from somewhere.<br>
<br>
You might also want to make sure that you are not breaking any other<br>
functionality that you currently rely on when you do this.<br>
<br>
This also wouldn't necessarily been spec compliant per se, although<br>
section <a href="http://3.1.3.6" target="_blank">3.1.3.6</a> of the 0-9 spec mentions the possibility of custom<br>
exchanges. So you would have to be comfortable with that.<br>
<br>
And, unless it was a really worthwhile addition, we probably wouldn't<br>
maintain it in the main Rabbit tree.<br>
<br>
Other than that, feel free to do so. We have talked about plugable<br>
queues before (although Matthias has rightly pointed out that this is<br>
much easier said than done) so why should exchanges be any different?<br>
<br>
But despite all of these practical considerations, there is a lot of<br>
merit to adding custom exchanges (which Kirk may interpret as custom<br>
routing algorithms :-), because the exchange is point in the AMQP<br>
pipeline with the greatest amount of leverage effect when it comes<br>
down to deciding which messages go where.<br>
<br>
HTH,<br>
<font color="#888888"><br>
Ben<br>
<br>
</font></blockquote></div><br></div>