Payload Passthru Mode in Crossbar

[om26er]

Crossbar has for a while support "opaque payloads", now renamed to Payload Passthru Mode with some modifications to the attributes. Nexus has now basic support for the new Payload Passthru Mode. Crossbar needs to be updated to the new spec so that the autobahn client libraries could be changed according to the new spec

Had a discussion with @oberstet and he said to create github issues.

The spec text lives here https://wamp-proto.org/wamp_latest_ietf.html#name-payload-passthru-mode

[oberstet]

since this is - at the wamp general level - a bigger feature (not only a bug fix or small addition), and since we only now have spec text for PPT, but we do have existing implementations in CB + ABx, I would propose the following approach with the goals:

• keep the current implementation in CB+ABx working,
• while we move to the now existing spec text, and
• add new other non-CB, non-AB impls at the same time

IOW: it is a matter of multiple, coordinated PRs

---

the first piece is:

1. add automated tests for "PPT only" as it is currently implemented in CB + ABx
2. modify CB to follow the now spec'ed PPT text - this will break the previous tests
3. fix ABx to make the tests work again
4. test 3rd party WAMP impl: any X with CB and ABx with any Y - both should work given above

[oberstet]

@KSDaemon ^ what do you think?

[oberstet]

rgd above approach, this is trying to address the problem of how to evolve and coordinate changes to multiple implementations conforming to a common spec.

and further, "implementations" of two categories: routers and client libraries.

the goal is:

• be able to run every client impl with every router impl, and have the client & router impls reflect the spec.
• and automated/CI tests should "prove above"

if we now evolve "PPT spec-v0" (no spec text, but just what happens to be implemented in CB, ABx) to "PPT spec-v1" (the new spec section for PPT we now have), how to sequence and coordinate changes, minimizing work and risk

[KSDaemon]

Well, I think that as there are no tests for current payload transparency and there are already implementations aligned with spec, should we put efforts into creating tests for the current implementation that we know differs from the spec? I mean that this work will be thrown away.
I suggest directly starting working on PPT mode with test coverage in a separate branch, so until we polish the tests and ensure that everything is okay, we won't merge, so no one using the current implementation will be affected.
At the same time, as this is not backward compatible change, I suggest to follow semver and update docs and release a new major version, so everyone can understand and take risks of blindly updating to new versions. At least our conscience will be clear!