All protocol message types should have options/details

[iddaspix]

Some protocol messages have a rigid structure:

[SUBSCRIBED, SUBSCRIBE.Request|id, Subscription|id]
[UNSUBSCRIBED, UNSUBSCRIBE.Request|id]
[REGISTERED, REGISTER.Request|id, Registration|id]
[UNREGISTERED, UNREGISTER.Request|id]
[PUBLISHED, PUBLISH.Request|id, Publication|id]

I think it would be a good idea that all protocol messages could be extensible with details or options. The final result could be:

[SUBSCRIBED, SUBSCRIBE.Request|id, Subscription|id]
[SUBSCRIBED, SUBSCRIBE.Request|id, Subscription|id, Details|dict]

[UNSUBSCRIBED, UNSUBSCRIBE.Request|id]
[UNSUBSCRIBED, UNSUBSCRIBE.Request|id, Details|dict]

[REGISTERED, REGISTER.Request|id, Registration|id]
[REGISTERED, REGISTER.Request|id, Registration|id, Details|dict]

[UNREGISTERED, UNREGISTER.Request|id]
[UNREGISTERED, UNREGISTER.Request|id, Details|dict]

[PUBLISHED, PUBLISH.Request|id, Publication|id]
[PUBLISHED, PUBLISH.Request|id, Publication|id, Details|dict]

Adding details to these messages allows for future extensibility (cfr. 6.1. Extensibility) and allows routers to inform clients about the state of the subscription/registration/publication giving more information if needed.

[oberstet]

this came up before - and it was a slight mistake not to include that in the first place, which we can however rectify in a straight forward way.

I am +1 on the proposed change. however, since this can/will break implementations, we need consensus from implementors first.

[konsultaner]

For me:

Pro:

• saving amount of messages when meta data is needed
• makes custom features possible

Cons:

• may make often used messages larger
• not strictly defined dicts take more serializer performance
• breaks current implementations -> all implementers would need to support both in order to be compatible with older versions

Since my implementation is commercial, I think I only have a half vote on it, but I would rather see breaking features in a next version.

[goeddea]

+1 (for what that's worth - not an implementer): from the number of requests for extensions of individual messages that I remember, it seems the best approach to have everything extensible once and for all.

[KSDaemon]

Good idea. Yes, the most important pitfall is backward incompatibility, as @konsultaner already mentioned. I think, i'll implement it in all my clients/router with backward compatibility in mind.

Yet another one thing: people can read WAMP spec, see this feature, but could be badly surprised not to find it in used wamp implementations...