Address impact of change to interface on extras field on Message

[QuintinWillison]

For 1.2.0 we changed Message.extras from JsonObject to MessageExtras.

This was a breaking change which we acknowledged as a TODO but never addressed.

We need to decide the approach for fixing this (either revert or extend the new MessageExtras class) in order to comply with TM2i.

[paddybyers]

Honestly I think extending MessageExtras is the way to go.

[mattheworiordan]

Why does this need to be a MessageExtras object when it's defined in the spec as JSON object?

In the spec:

extras JSON-encodable object, used to contain any arbitrary key value pairs which may also contain other primitive JSON types, JSON-encodable objects or JSON-encodable arrays. The extras field is provided to contain message metadata and/or ancillary payloads in support of specific functionality, e.g. push. Each of these supported extensions is documented separately; for 1.1 the only supported extension is push, via the extras.push member; 1.2 adds the delta extension which is of type DeltaExtras. The processing of any other members is undefined

If we go with a typed MessageExtras object, then every change we make in the protocol needs to be co-ordinated with an SDK change, which creates an unnecessary coupling and slows getting features to customers out.

[mattheworiordan]

Related ably/docs#1639.

[SimonWoolf]

I have to agree with Matt - the spec item envisaged a json blob, opaque to the client library, so we could add new features without having to make painful client lib changes, or have to encode the knowledge of how all the push payloads are structured in each client lib, etc. I haven't seen anyone give a good reason for us to change that plan. (Of course typed languages might well want to parse extras.delta on incoming messages into a DeltaExtras object before interacting with it, but they can still do that)

[mattheworiordan]

@QuintinWillison are there any other SDKs which have gone down this route in 1.2 and deviated from the spec?

[QuintinWillison]

@mattheworiordan off topic for this issue and repository context. Moved to internal Slack conversation for the moment, until we have an explicit issue or issues to create in other repositories. Thanks.