[rabbitmq-discuss] [BUG] Erlang RabbitMQ client requires installed server code

[Ben Hood]

Edwin,

On Mon, Sep 8, 2008 at 12:47 AM, Edwin Fine
<rabbitmq-discuss_efine at usa.net> wrote:
> With all due respect in return, check out this code from
> amqp_connection.erl:
>
> %% Starts a new network channel.
> handle_call({network, ChannelNumber, OutOfBand}, From, State) ->
>     handle_start({ChannelNumber, OutOfBand},
>                  fun amqp_network_driver:open_channel/3,
>                  fun amqp_network_driver:close_channel/1,
>                  fun amqp_network_driver:do/2,
>                  fun amqp_network_driver:do/3,
>                  State);
>
> %% Starts a new direct channel.
> handle_call({direct, ChannelNumber, OutOfBand}, From, State) ->
>     handle_start({ChannelNumber, OutOfBand},
>                  fun amqp_direct_driver:open_channel/3,
>                  fun amqp_direct_driver:close_channel/1,
>                  fun amqp_direct_driver:do/2,
>                  fun amqp_direct_driver:do/3,
>                  State);
>
> This ties the module to amqp_direct_driver by naming it. xref will show this
> code is dependent on amqp_direct_driver. Dialyzer will complain if
> amqp_direct_driver is not there. This call should be handled somewhere else.
> In my humble opinion.

This is a valid point. We should look into splitting this out somehow.
I don't have an answer straight away, but I'm sure we can come up with
something.

>>
>>
>> > amqp_network_driver calls rabbit_framing_channel, which in turn calls
>> > rabbit_channel. So indirectly, the network client uses rabbit_channel
>> > and
>> > needs it in the common distribution.
>>
>> This is true, but this only pertains to the do/2 and do/3 calls, which
>> *could* be abstracted out of the rabbit_channel module with not too
>> many changes.
>
>
> Well, then, let's factor it out.

I'll take this down as a point of discussion as well.

Cheers,

Ben