crossbario / crossbar

Crossbar.io - WAMP application router
https://crossbar.io/
Other
2.05k stars 275 forks source link

Payload Passthru Mode in Crossbar #2056

Open om26er opened 2 years ago

om26er commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

@KSDaemon ^ what do you think?

oberstet commented 2 years ago

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:

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 commented 2 years ago

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!