AnyEvent-RabbitMQ

 view release on metacpan or  search on metacpan

share/fixed_amqp0-8.xml  view on Meta::CPAN

        <rule implement="MUST">
      The client MUST provide a valid access ticket giving "active"
      access rights to the exchange's access realm.
    </rule>
      </field>
      <field name="exchange" domain="exchange name">
        <rule implement="MUST">
          <test>amq_exchange_11</test>
      The exchange MUST exist. Attempting to delete a non-existing exchange
      causes a channel exception.
    </rule>
        <assert check="notnull"/>
      </field>
      <field name="if unused" type="bit">
    delete only if unused
    <doc>
      If set, the server will only delete the exchange if it has no queue
      bindings. If the exchange has queue bindings the server does not
      delete it but raises a channel exception instead.
    </doc>
        <rule implement="SHOULD">
          <test>amq_exchange_12</test>
      If set, the server SHOULD delete the exchange but only if it has
      no queue bindings.
    </rule>
        <rule implement="SHOULD">
          <test>amq_exchange_13</test>
      If set, the server SHOULD raise a channel exception if the exchange is in
      use.
    </rule>
      </field>

  <field name = "nowait" type = "bit">
    do not send a reply method
    <doc>
    If set, the server will not respond to the method. The client should
    not wait for a reply method.  If the server could not complete the
    method it will raise a channel or connection exception.
    </doc>
  </field>

    </method>
    <method name="delete-ok" synchronous="1" index="21">
  confirm deletion of an exchange
  <doc>
    This method confirms the deletion of an exchange.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
  </class>
  <class name="queue" handler="channel" index="50">
    <!--
======================================================
==       QUEUES
======================================================
-->
  work with queues

<doc>
  Queues store and forward messages.  Queues can be configured in the server
  or created at runtime.  Queues must be attached to at least one exchange
  in order to receive messages from publishers.
</doc>
    <doc name="grammar">
    queue               = C:DECLARE  S:DECLARE-OK
                        / C:BIND     S:BIND-OK
                        / C:PURGE    S:PURGE-OK
                        / C:DELETE   S:DELETE-OK
</doc>
    <chassis name="server" implement="MUST"/>
    <chassis name="client" implement="MUST"/>
    <rule implement="MUST">
      <test>amq_queue_33</test>
  A server MUST allow any content class to be sent to any queue, in any
  mix, and queue and delivery these content classes independently. Note
  that all methods that fetch content off queues are specific to a given
  content class.
</rule>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="declare" synchronous="1" index="10">
  declare queue, create if needed
  <doc>
    This method creates or checks a queue.  When creating a new queue
    the client can specify various properties that control the durability
    of the queue and its contents, and the level of sharing for the queue.
  </doc>
      <rule implement="MUST">
        <test>amq_queue_34</test>
    The server MUST create a default binding for a newly-created queue
    to the default exchange, which is an exchange of type 'direct'.
  </rule>
      <rule implement="SHOULD">
        <test>amq_queue_35</test>
    The server SHOULD support a minimum of 256 queues per virtual host
    and ideally, impose no limit except as defined by available resources.
  </rule>
      <chassis name="server" implement="MUST"/>
      <response name="declare-ok"/>
      <field name="ticket" domain="access ticket">
        <doc>
      When a client defines a new queue, this belongs to the access realm
      of the ticket used.  All further work done with that queue must be
      done with an access ticket for the same realm.
    </doc>
        <doc>
      The client provides a valid access ticket giving "active" access
      to the realm in which the queue exists or will be created, or
      "passive" access if the if-exists flag is set.
    </doc>
      </field>
      <field name="queue" domain="queue name">
        <rule implement="MAY">
          <test>amq_queue_10</test>
      The queue name MAY be empty, in which case the server MUST create
      a new queue with a unique generated name and return this to the
      client in the Declare-Ok method.
    </rule>
        <rule implement="MUST">
          <test>amq_queue_32</test>
      Queue names starting with "amq." are reserved for predeclared and
      standardised server queues.  If the queue name starts with "amq."



( run in 0.566 second using v1.01-cache-2.11-cpan-e1769b4cff6 )