This is the entire "Wire transport" DTO of MatsSocket. For each
MessageType, a certain set of
its properties needs to be present, with a couple of optional fields (chiefly 'desc', 'rd' and 'debug'). Note
that any message may contain the 'auth' field, thus updating the Server's "cached" Authorization value - it must
be present with (or before, but hey) the HELLO message. It may also be present with a dedicated
AUTH message.
Note: For information: The
msg-field (which is defined as
Object) is handled rather
specially: The serialization/deserialization-mechanism in the MatsSocket implementation is configured to treat it
differently depending on whether it is deserialized or serialized: When a message is incoming from the Client,
the 'msg' field is not deserialized to a specific type - instead it contains the "raw JSON" of the incoming DTO
as a String. This is necessary since we do not know the type of which DTO object is represented there until we've
figured out what MatsSocket endpoint is targeted - at which time we can deserialize it to the type that
MatsSocket Endpoint expects. On serialization, the message object is serialized separately from the Envelope -
and then plugged into the Envelope on the 'msg' field using a "direct JSON" technique.
Note: When instances of this the Envelope DTO is exposed via the MatsSocket API via listeners or the
LiveMatsSocketSession.getLastEnvelopes(), the contents of the
'msg' will always be a String representing the JSON serialized message - it will NOT be an instance of a DTO
class. This ensures that the entire Envelope can be sent as a Mats or MatsSocket message, should that be of
interest.
Also, exposed Envelopes will be as instances of MatsSocketEnvelopeWithMetaDto!.
Note: Copying out the source of
MatsSocketEnvelopeDto PLUS
MatsSocketEnvelopeWithMetaDto and including it in the source of another
service (or just importing the MatsSocket jar into that service), you can pass the entire Envelope as (part of) a
Mats DTO.