Specify header in messages

[Nockm]

Any thoughts about adding a message header to easily support multiple message types in the future? e.g.

{
  "header": "pad_update",
  "data": {
    "BUTTON_X": true,
    "BUTTON_Y": true
  }
}

{
  "event": "padupdate",
  "payload": {
    "BUTTON_X": true,
    "BUTTON_Y": true
  }
}

[electronstudio]

is there any advantage to having payload in separate object? if not, then simpler is flat structure:

{
  "event": "padupdate",
  "BUTTON_X": true,
  "BUTTON_Y": true
}

[electronstudio]

But you could even consider BUTTON_X and BUTTON_Y to be the message type, i.e.:

{
  "BUTTON_X": true
},
{
  "BUTTON_Y": true
}

[Nockm]

is there any advantage to having payload in separate object? if not, then simpler is flat structure

I think it's more maintainable. Later on if we have more message types parameter keys will clash, making future logic to discern the message type harder.

e.g. Maybe in the future, a different message might want BUTTON_X to refer to some sort of customisation request for the X button instead of a pad state update.

[electronstudio]

in that case perhaps BUTTON_X should be a value instead of a key?

{
  "event": "padupdate",
  "payload": {
    "field": "BUTTON_X",
    "value:": true
  }
}

[Nockm]

That seems more verbose to me.

Conceptually I think of these messages as invoking a remote method: the event is the method and the payload is the parameters.

[electronstudio]

If you're thinking of it as having statically typed parameters then the keys should be the same every time, no?

{
  "type": "button_update",
  "data": {
    "button_id": "BUTTON_X",
    "button_state:": true
  }
}

Which un-serializes to a statically typed object:

class ButtonUpdate: Update{
   int button_id;
   boolean button_state
}

Or for an axis:

{
  "type": "axis_update",
  "data": {
    "axis_id": "AXIS_LEFTY",
    "axis_state": 0.354
  }
}

[Nockm]

That looks good for updating a single button or axis at a time. In our case we're updating the state with a delta. So I thought this would work:

{
  "type": "pad_update",
  "data": {
     ... same delta pad state that we currently transmit ...
  }
}

I'm thinking though that I'm not seeing the spirit of what you mean, so I need to understand that first!

From my POV, the above has the intent of the message made explicit via type, the relevant params in data, and is simple for the client to construct; what's not to like! However maybe that might be annoying to deserialize?

[Nockm]

Offline conclusion:

{
  "__type__": "pad_update",
   ... data ...
}