view release on metacpan or  search on metacpan

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

	<test>amq_queue_27</test>
        <doc>
      If set, the server will only delete the queue if it has no
      messages. If the queue is not empty the server raises a channel
      exception.
    </doc>
      </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="41">
  confirm deletion of a queue
  <doc>
    This method confirms the deletion of a queue.
  </doc>
      <chassis name="client" implement="MUST"/>
      <field name="message count" type="long">
    number of messages purged
    <doc>
      Reports the number of messages purged.
    </doc>
      </field>
    </method>
  </class>
  <class name="basic" handler="channel" index="60">
    <!--
======================================================
==       BASIC MIDDLEWARE
======================================================
-->
  work with basic content
<doc>
  The Basic class provides methods that support an industry-standard
  messaging model.
</doc>

<doc name = "grammar">
    basic               = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK
                        / C:CANCEL S:CANCEL-OK
                        / C:PUBLISH content
                        / S:RETURN content
                        / S:DELIVER content
                        / C:GET ( S:GET-OK content / S:GET-EMPTY )
                        / C:ACK
                        / C:REJECT
</doc>

<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MAY"  />

<doc name = "rule" test = "amq_basic_08">
  The server SHOULD respect the persistent property of basic messages
  and SHOULD make a best-effort to hold persistent basic messages on a
  reliable storage mechanism.
</doc>
<doc name = "rule" test = "amq_basic_09">
  The server MUST NOT discard a persistent basic message in case of a
  queue overflow. The server MAY use the Channel.Flow method to slow
  or stop a basic message publisher when necessary.
</doc>
<doc name = "rule" test = "amq_basic_10">
  The server MAY overflow non-persistent basic messages to persistent
  storage and MAY discard or dead-letter non-persistent basic messages
  on a priority basis if the queue size exceeds some configured limit.
</doc>
<doc name = "rule" test = "amq_basic_11">
  The server MUST implement at least 2 priority levels for basic
  messages, where priorities 0-4 and 5-9 are treated as two distinct
  levels. The server MAY implement up to 10 priority levels.
</doc>
<doc name = "rule" test = "amq_basic_12">
  The server MUST deliver messages of the same priority in order
  irrespective of their individual persistence.
</doc>
<doc name = "rule" test = "amq_basic_13">
  The server MUST support both automatic and explicit acknowledgements
  on Basic content.
</doc>

<!--  These are the properties for a Basic content  -->

<field name = "content type" type = "shortstr">
    MIME content type
</field>
<field name = "content encoding" type = "shortstr">
    MIME content encoding
</field>
<field name = "headers" type = "table">
    Message header field table
</field>
<field name = "delivery mode" type = "octet">
    Non-persistent (1) or persistent (2)
</field>
<field name = "priority" type = "octet">
    The message priority, 0 to 9
</field>
<field name = "correlation id" type = "shortstr">
    The application correlation identifier
</field>
<field name = "reply to" type = "shortstr">
    The destination to reply to
</field>
<field name = "expiration" type = "shortstr">
    Message expiration specification
</field>
<field name = "message id" type = "shortstr">
    The application message identifier
</field>
<field name = "timestamp" type = "timestamp">
    The message timestamp
</field>
<field name = "type" type = "shortstr">
    The message type name

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

    This method asks the broker to redeliver all unacknowledged messages on a
    specifieid channel. Zero or more messages may be redelivered.
  </doc>
  <chassis name = "server" implement = "MUST" />

  <field name = "requeue" type = "bit">
    requeue the message
    <doc>
      If this field is zero, the message will be redelivered to the original recipient.  If this bit
      is 1, the server will attempt to requeue the message, potentially then delivering it to an
      alternative subscriber.
    </doc>
  </field>

    <doc name="rule">
      The server MUST set the redelivered flag on all messages that are resent.
    </doc>
    <doc name="rule">
    The server MUST raise a channel exception if this is called on a transacted channel.
    </doc>
</method>


</class>


  <class name="file" handler="channel" index="70">
    <!--
======================================================
==      FILE TRANSFER
======================================================
-->
  work with file content
<doc>
  The file class provides methods that support reliable file transfer.
  File messages have a specific set of properties that are required for
  interoperability with file transfer applications. File messages and
  acknowledgements are subject to channel transactions.  Note that the
  file class does not provide message browsing methods; these are not
  compatible with the staging model.  Applications that need browsable
  file transfer should use Basic content and the Basic class.
</doc>

<doc name = "grammar">
    file                = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK
                        / C:CANCEL S:CANCEL-OK
                        / C:OPEN S:OPEN-OK C:STAGE content
                        / S:OPEN C:OPEN-OK S:STAGE content
                        / C:PUBLISH
                        / S:DELIVER
                        / S:RETURN
                        / C:ACK
                        / C:REJECT
</doc>

<chassis name = "server" implement = "MAY" />
<chassis name = "client" implement = "MAY" />

<doc name = "rule">
  The server MUST make a best-effort to hold file messages on a
  reliable storage mechanism.
</doc>
<doc name = "rule">
  The server MUST NOT discard a file message in case of a queue
  overflow. The server MUST use the Channel.Flow method to slow or stop
  a file message publisher when necessary.
</doc>
<doc name = "rule">
  The server MUST implement at least 2 priority levels for file
  messages, where priorities 0-4 and 5-9 are treated as two distinct
  levels. The server MAY implement up to 10 priority levels.
</doc>
<doc name = "rule">
  The server MUST support both automatic and explicit acknowledgements
  on file content.
</doc>

<!--  These are the properties for a File content  -->

<field name = "content type" type = "shortstr">
    MIME content type
</field>
<field name = "content encoding" type = "shortstr">
    MIME content encoding
</field>
<field name = "headers" type = "table">
    Message header field table
</field>
<field name = "priority" type = "octet">
    The message priority, 0 to 9
</field>
<field name = "reply to" type = "shortstr">
    The destination to reply to
</field>
<field name = "message id" type = "shortstr">
    The application message identifier
</field>
<field name = "filename" type = "shortstr">
    The message filename
</field>
<field name = "timestamp" type = "timestamp">
    The message timestamp
</field>
<field name = "cluster id" type = "shortstr">
    Intra-cluster routing identifier
</field>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "qos" synchronous = "1" index = "10">
  specify quality of service
  <doc>
    This method requests a specific quality of service.  The QoS can
    be specified for the current channel or for all channels on the
    connection.  The particular properties and semantics of a qos method
    always depend on the content class semantics.  Though the qos method
    could in principle apply to both peers, it is currently meaningful
    only for the server.
  </doc>