Polymorphic Messages about wamp-proto HOT 6 CLOSED

+1

from wamp-proto.

+1

I was about to complain about this until I read the v2 spec.

As I commented on another issue, messages of type P2 should allow the last element to be variadic for some messages, with the statement that libraries can represent multiple elements as a List. A variadic message type cannot be extended, and future changes must define a new message type. This should keep things simple while maintaining backwards compatibility.

from wamp-proto.

Good point: "only allow P1 and P2" isn't a sufficiently precise design criteria.

The current WAMPv2 proposal has

[CALL_RESULT,   CallID|string, CallResult|any]

which does not allow multi return, but future extensibility .. e.g.

[CALL_RESULT,   CallID|string, CallResult|any, CallResultMeta|any]

If I get you right, you propose

[CALL_RESULT,   CallID|string, CallResult1|any]
[CALL_RESULT,   CallID|string, CallResult1|any, CallResult2|any]
...

which would then require to add a new, additional message variant for the above example

[CALL_RESULT_B,   CallID|string, CallResultMeta|any, CallResult1|any]
[CALL_RESULT_B,   CallID|string, CallResultMeta|any, CallResult1|any, CallResult2|any]
...

from wamp-proto.

Yes, that's exactly what I propose. I've made a different suggestion on issue #21 that would allow extensibility and multi-return, but it changes the v1 behavior. Since v2 is already backwards incompatible with v1 (PUBLISH for example), I didn't feel too bad about making that suggestion, and it may be a better solution moving forward.

from wamp-proto.

Reading/thinking right now .. will comment .. but rgd. backware compat. - don't worry, I agree - we should make a clear cut (once .. now). Due to my stupidity, the versioning that WAMPv1 claims/suggests to support is severly broken anyway. See: #23

from wamp-proto.

WAMPv2 messages address much of above by having a builtin extension point (options or details dicts) and cleanup much of the WAMPv1 message format mess.

There is however another requirement (desirable goal) in WAMPv2: the application payload (that is call arguments, returns, event payload etc) must be at the end of the WAMP message list. The reason is: brokers and dealers have no need to inspect (parse) that application payloads. Their business is call/event routing. Having the application payload at the end of the list allows brokers/dealers skip parsing altogether. This improves efficiency/performance and probably even allows to transport application encrypted payload transparently.

from wamp-proto.