6.8. List of messages

<message role="ROLE LIST" method="METHOD NAME">
    <description>
        Description of this message here.
    </description>
    <field name="FIELD NAME" optional="yes OR no">
        <description>
            Description of the field here.
        </description>
        <default>default value</default>
    </field>
    ...
    <reply method="REPLY METHOD" />
    ...
</message>

        

Here list each message that this type understands and responds to. Use a message element for each message.

Method names may contain only alphanumeric characters, or dash ('-'). A colon may be also be used, but only in the way described below.

Different types may accept the same method name. While clients may control how messages are passed to metaobject handlers, in almost all cases the behavior should be to pass the message to all types which accept that method.

To help prevent method name conflicts between types, use this naming convention: prepend the method name with the type's group name and a colon:

group:action-name

The role attribute indicates how the message is used by this object. A role of "update" indicates that the message is always sent as a remote-update (an "<update>" message from local to remote objects). A role of "emits" indicates that this message is sent by this object. A role of "accepts" indicates that this message is accepted by this object. Seperate role tags with commas and/or whitespace (e.g. "emits, accepts").

The field element defines a message field. If the field is optional, use the value "yes" for the optional attribute. If omitted, optional defaults to "no". If a field is optional, you may supply a default value using the default element. Use a field element for each message field.

The reply element references a message defined in another message element, either before or after the current message. Include a reply element for each possible reply.