Messages

Specification vs Instantiation vs Transport

Bayeux messages:

• are specified in JSON.
• should be instantiated in the natural object representation of the language used for the client/server.
• may be transported via any appropriate serialization that the specific transport supports. This may be a JSON String, an XML document or some other serialization.

A simple Bayeux message could be specified as:

{channel:"/some/channel",data:[1,2,3]}

This message has a natural instantiation in Javascript. The message could be transported as a wire format that uses the JSON as described above, or the instantiated Javascript objects could be serialized to XML if some transport wished. If delivered to a Java Bayeux implementation, then the message would be instantiated as a java.util.Map<String,Object> instance that contained java.lang.String keys and values of type java.lang.String and java.util.Array<Object>.

Reserved Fields

All fields in the top level of a JSON message are reserved for the use of the protocol. The following fields are the most important defined fields:

channel

All messages MUST have a channel field with a string value that identifies the handler for the message.

clientId

A message MAY have a clientId field with a string value that identifies the client. ClientIDs are only unique within a single non-cluster Bayeux server and are only valid for the duration of the Bayeux connected state. They should be considered roughly equivalent to a HTTP session ID and treated the same with regards to security and longevity.

id

Any message MAY contain an id field with a string value that identifies the message. The id is generated by the creator of the message and its uniqueness or otherwise is application-specific.

data

The message payload. An arbitrary object

advice

Transport-specific parameters.

ext

Extension space

successful

Indicates the success of a protocol operation. Used in a response message

error

Error code and message