ADC message layout

A private forum for us Super-Humans, I even trust you to be able to edit your own posts =)

Moderator: Moderators

Posts: 34
Joined: 2003-05-01 10:49

ADC message layout

Post by FarCry » 2006-02-04 09:02

I've already mentioned most of it on the dev hub, but I'd like to wrap the topic up here for a hopefully more conclusive discussion:

I see the separation of message type and action type in ADC messages as a fundamental concept and, although the message is always there as a whole and whatever layout is chosen won't make it impossible for the implementation to process it, I'd like that distinction to be expressed as best as possible in the syntax. OO design is often considered as a good approach to break an implementation into smaller parts and there are some obvious ways to express the distinction of message types and action types in C++ and similar languages in a class hierarchy. I don't want to go into details here, but I think it might be helpful to bear such a concept in mind.

In the light of this, I'd like to see parameters belonging to a message type strictly separated from those that belong to the action type. The ADC 0.10pre5 draft rather seems to consider the message as a whole and parsing an independent step. That introduces some inconsistencies and conceptual amibiguities. For example:
- Message type I has a <my_sid> parameter that can only ever be "BAAA" for a valid message. That favors lax parsing, only considering either the message type or the <my_sid> parameter. A strict implementation would always have to check both. Redundant and ambiguous.
- Message type H also has the <my_sid> field, although only the SID of the client on that connection is valid. A hub should be strict in message handling to avoid doing things the client doesn't want and report failure correctly, so it has to check that field. The first client's HSUP also has to be a special case, since it doesn't know its SID at that point.
- Message type U carries the CID in a named parameter somewhere in the parameter list. While messages on the hub connection favor early parsing (extract the <my_sid> before looking at anything else), a client would have to check the action first, to drop the whole message and avoid looking for the ID field if it's unknown. Furthermore, named parameters don't appear in the specs for any of the other types. A named parameter is a concept of the action type in my opinion.

To sum it up, the message layout should look like this:
I, C and H types: no additional parameters.
U type: first parameter is the <my_cid>.
B (A, T) type(s): first parameter is the <my_sid>.
D type: first parameter is the <my_sid>, second is the <target_sid>

There can still be reserved SID:s to simplify client implementations, but the hub doesn't have to have a notion of an SID for itself anymore. Obscure constructs like D-type messages originating from or targeting the hub, like the current specs conceptually allow, aren't an issue anymore.

That way we have all message type related parameters in front of action type parameters. They are still not fully independently parseable, but we'd need a special separator for that. I don't know if it's worth it, although it would allow implementations that my proposal doesn't.