[rabbitmq-discuss] Queue.declare arguments

[David Wragg]

Hi Pieter,

Pieter de Zwart <pdezwart at rubiconproject.com> writes:
> I am trying to implement support for passing arguments to
> queue.declare in the PHP extension for AMQP. Based on the docs,
> arguments are up to the server to implement, but are based on an
> amqp_table_t structure. Based on previous email threads and some basic
> research, the full list of supported keys for the table seem to be:
> x-expires, x-message-ttl, x-ha-policy and x-ha-policy-params. Is this
> still the complete list? It seems like I should just give people the
> ability to set any key they want.

Yes.  Even if that list is complete today, it might not be complete in
the future.

> The definition of an amqp_table_entry is a key (amqp_bytes) and value
>(amqp_field_value_t). The latter has a definition of:
>
> typedef struct amqp_field_value_t_ { char kind; union { amqp_boolean_t
> boolean; int8_t i8; uint8_t u8; int16_t i16; uint16_t u16; int32_t
> i32; uint32_t u32; int64_t i64; uint64_t u64; float f32; double f64;
> amqp_decimal_t decimal; amqp_bytes_t bytes; amqp_table_t table;
> amqp_array_t array; } value; } amqp_field_value_t;
>
> Im assuming therefore that I can shove any kind/value combo for any
> key, and let the rabbitmq-c client/broker figure out the details. Is
> that correct?

Yes.  AMQP tables are just name -> typed value dictionaries.  In certain
contexts (such as queue.declare arguments) the broker defines a
particular meaning for them.  In others (e.g. message headers) the
interpretation is up to applications. (Actually, this is not entirely
true for message headers any more - there are RabbitMQ protocol
extensions that involve certain message headers influencing broker
behaviour).

See
<https://github.com/rabbitmq/rabbitmq-c/blob/master/tests/test_tables.c>
for rabbitmq-c code that constructs tables.

-- 
David Wragg
Staff Engineer, RabbitMQ
VMware, Inc.