Allow control over exchange creation

[nahpeps]

I recognized that is is not possible to control the process of creating an exchange.

In the Sub and Pub.connect functions the exchange is always created with a predefined set of exchange options:

ch.assertExchange(source,
                      this.options.routing || 'fanout',
                      {durable: false, autoDelete: false})
      .then(function(ok) {
        return ch.bindQueue(queue, source, topic);
      })
      .then(callback);
  }

Here the setting is always {durable: false, autoDelete: false}).

It would be really great to have the chance to overwrite these settings in the exchange creation.
This issue is to #63.

I would like to do something like:

ch.assertExchange(source,
                      this.options.routing || 'fanout',
                     exchangeOptions)
      .then(function(ok) {
        return ch.bindQueue(queue, source, topic);
      })
      .then(callback);
  }

[omniadonum]

+1 Could really use this feature. noCreate either puts a burden on the sysadmin role, or creates a manual step for the application owner. It appears that this flexibility exists in Ruby's RabbitMQ lib, so I'm not sure regarding the reason for the handicap.

[squaremo]

It appears that this flexibility exists in Ruby's RabbitMQ lib, so I'm not sure regarding the reason for the handicap.

This flexibility also exists in https://github.com/squaremo/amqp.node. Calling it a handicap here is not very fair: the idea of rabbit.js is to make using RabbitMQ transparently easy, and that means eliding options that don't matter for the socket-like abstractions given.

I am starting to think that the socket-like abstractions are the less useful bit. Would it be better to just have ways, in amqplib, of publishing and consuming via streams?

[omniadonum]

@squaremo I am new to RabbitMQ (and AMQP in general), and am under the impression that amqp.node is for any service that supports AMQP, while rabbit.js is specific to the RabbitMQ flavor and its individual paradigms. I could be wrong and incorrectly aligned with this project's goals, so I apologize for that.

With this in mind, considering RabbitMQ's management interface (see /api/exchanges/vhost/name) reveals AMQP's underlying e.g. durable option, I would expect it to be presented in rabbit.js.

Perhaps omitting functionality (e.g. options) altogether is less favorable than having them available but with intrinsic defaults. There already exists a hint of this with routing being fanout.

From a beginners perspective, the current socket-like abstractions are useful organizationally speaking, albeit I don't personally use them in a stream context (yet).

[nahpeps]

I am also new in rabbit.js and the whole node.js context. For me, the abstraction of using sockets instead of streams was very helpful, because I don't need to deal with the pitfalls of streams, but use a concept that I know in general.

But of course I also read the RabbitMQ documentation and was irritated because I was not able to create an autoDelete exchange until I digged into the source.

So just adding the possibility to give, maybe optional, settings to the socket creation which then are merged with a default option set, would be a great thing.