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

[Edwin Fine]

Matthias,


> Bear in mind that the Erlang client code base can operate in both direct
> and networked mode. For the former you definitely need a server.


I do understand, but there should be separate direct network clients. I
think it's asking for trouble, and untidy, to have references in code to
something that it will never use and will crash if it ever magically does
try to use it. It also confuses dependency analysis tools. I want to build a
release consisting only of modules that are needed for a network client, for
a sort of embedded server scenario. As things stand now, I will have to pull
in some or all of the rabbitmq_server application, and I will have to have
the server code installed on the build system even if I am never going to
use it on that system. Maybe I am being picky here (call me "purist", if you
must), but that doesn't feel right to me. I didn't need the server code to
build client-related code with WebSphere MQ.

 I respectfully suggest that the above RabbitMQ server modules, and their
> dependencies, be bundled with the Erlang client. Ideally, I would think it
> would be best perhaps to put them a separate Erlang library application
> (maybe "rabbitmq_common") that is used both by the server and the Erlang
> client.
>

The above is on our todo list. Refactoring the code is the easy part. The
> challenges are in:
>
> - updating the module structure of the VCS - is rabbitmq_common going to be
> a separate HG module?


That depends. Is it something that is reusable in a number of contexts? If
so, I would say yes, although I am not sure what the HG-specific
consequences are of having a separate HG module.


> - figuring out how rabbitmq_common will be distributed. This can be a
> combination of all of the following: a) separately, b) as part of the Erlang
> client and server source packages, c) as part of the Erlang client and
> server binary packages. Then there also the Debian and RPM packages to
> consider - are we going to have a separate packages for rabbitmq_common or
> will it be bundled with the existing packages?


I think of this as a library on which multiple different applications
depend, something like glibc. It needs to be there, in the correct version,
before you can install packages that depend on it. So it needs to be a
separately installable app. rabbitmq_server.app, rabbitmq_direct_client.app,
and rabbitmq_network_client.app will all show rabbitmq_common as an
included_application.

If you do this, I believe it fits in to the Debian/RPM/Yum/YaST/Uncle Tom
Cobbleigh and all's dependency model.

Depending on the above choices a significant amount of work needs to be put
> into revising the build system, the packaging system, our automated
> deployment system, the documentation, and parts of the web site.
>

That's for sure!


>
> That's why it hasn't happened yet.
>

I understand. I was just caught by surprise trying to create what is
effectively an embedded client. I've been trying to tease apart the
dependencies of many products for a few days now :(

Regards,
>
> Matthias.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080907/2e675e0b/attachment.htm