[rabbitmq-discuss] rabbitmq-c and amqp_send_frame_to

Wed Feb 16 11:26:16 GMT 2011

Hi Mike,

mike castleman <m at mlcastle.net> writes:
> Is there any chance of amqp_send_frame_to() coming back? Or is there any
> other suggested way to make librabbitmq construct a frame without
> immediately sending it onto the socket?
>
> It is possible that for our application the frames are generally going
> to be small, so we might only call amqp_send_frame() when the socket is
> ready for writing and hope that the send() call inside there won't ever
> block (or return EWOULDBLOCK). But this seems fragile, to say the
> least.

rabbitmq-c development is focused on its use as a self-contained AMQP
client. We try to preserve the API functions aimed at typical AMQP
client applications, rather than ones that seem more like librabbitmq
internals (as this makes evolving the library difficult - librabbitmq
exposes way too much of its internals, IMHO).

(There's a trade-off in library design, particularly for C: One option
is that library can expose clearly designated public APIs.  The upside
is that further development of that library is easy - you simply have to
make sure that you preserve the APIs an their behaviour.  The downside
is that the library can only really support the use cases envisaged when
those APIs were designed.  The other option is to expose more or less
everything, and allow applications to use the library as a "toolbox".
The upside here is that is it probably possible to make the library
serve a wide range of use cases, as applications can borrow whatever
functionality is relevant and ignore the rest.  The downside is that
this tends to freeze the implementation, and would make it difficult to
provide good documentation.)

Perhaps the appropriate thing is to fork a version of rabbitmq-c that
meets your needs on github?

With that said, if we received a nice patch that restored
amqp_send_from_to (and we'd need the author to sign our contributor
agreement), I expect we would incoporate that.  But I can't promise that
we wouldn't remove the function again later on.

As I may have mentioned before, it is our goal to release a C client
that does support non-blocking support nicely at some point in the
future.  But this is likely to be done by having an API specifically
designed for that use case.

David

-- 
David Wragg
Staff Engineer, RabbitMQ
SpringSource, a division of VMware