Comments (4)
I think these aren't incompatible, so I would vote for having both informations.
Feature announcement is a nice idea, but I would maintain basic compatibility with previous WAMPv1's WELCOME message, adding a version number (2) in the HELLO message:
[HELLO, SessionID|string, version|integer, HelloDetails|dict]
version = 2
HelloDetails={serverSessionID?, agent?, features?, roles?}
from wamp-proto.
The problem is: with WAMPv1, a client won't send anything to the server until it has received the WELCOME
message from the server. So the server does not know which protocol version the client speaks, and if we want to maintain compatibility, the server needed to send
[ TYPE_ID_WELCOME , sessionId , protocolVersion = 2, serverIdent ]
Since there is not client-to-server WELCOME message, the server won't ever know which protocol version the client supports. So we have 2 options: the server will later use WAMPv2 features / message structure (incompatible with WAMPv1), and the only valid client behavior would be to immediately bail out after receiving a WELCOME
from the server with protocolVersion = 2
. Or: don't change the message structure of WAMPv2 vs v1.
Anyway you put it, I think the "versioning" that WAMPv1 claims to support is severly broken. Its my fault. I havent put enough thought into it. Sorry, but I think it's broken enough to make a clear cut. And if we make a clear cut, then my suggestion is not to fix "versioning", but to drop it altogether and instead implement "feature announcement" and built in extensibility points (like the dict options present in various messages).
from wamp-proto.
The problem is: with WAMPv1, a client won't send anything to the server until it has received the WELCOME
message from the server. So the server does not know which protocol version the client speaks, and if we want to maintain compatibility, the server needed to send
[ TYPE_ID_WELCOME , sessionId , protocolVersion = 2, serverIdent ]
Since there is no client-to-server WELCOME message, the server won't ever know which protocol version the client supports. So we have 2 options: the server will later use WAMPv2 features / message structure (incompatible with WAMPv1), and the only valid client behavior would be to immediately bail out after receiving a WELCOME
from the server with protocolVersion = 2
. Or: don't change the message structure of WAMPv2 vs v1.
Anyway you put it, I think the "versioning" that WAMPv1 claims to support is severly broken. Its my fault. I havent put enough thought into it. Sorry, but I think it's broken enough to make a clear cut. And if we make a clear cut, then my suggestion is not to fix "versioning", but to drop it altogether and instead implement "feature announcement" and build in extensibility points (like the dict options present in various messages).
from wamp-proto.
WAMPv2 has (extensible) feature announcement via the HELLO
message: https://github.com/tavendo/WAMP/tree/master/spec#hello-and-goodbye
from wamp-proto.
Related Issues (20)
- Web site: Add stuff to "Users and Resources" section HOT 10
- Best practice for error answer? HOT 1
- Unspecified Behavior for Callee Leaving During CALL HOT 19
- Unclear behavior for caller leaving during CALL request HOT 7
- Propagation of frozen options in progressive call invocations HOT 6
- Error URI for expired progressive call race condition HOT 3
- Is `wamp.close.goodbye_and_out` deprecated in favor of `wamp.close.normal`? HOT 5
- `wamp.error.no_such_session` is not documented HOT 1
- `wamp.registration.match` matching algorithm is undefined HOT 3
- Should subscriptions to meta events fire the `wamp.subscription.on_subscribe` event? HOT 1
- Tolerating old CALL request IDs when progressive invocations are supported HOT 4
- Add Payload to Abort HOT 28
- Add `REGISTER.Options.forward_timeout` option HOT 2
- Broken Applet on wamp-proto.org
- Equivalent of 500 Internal Server Error in WAMP HOT 5
- Incorrect maximum raw socket limit HOT 1
- Error URI for Rate Limiting Purposes HOT 25
- Add AsyncAPI to comparison on web site
- Update spec contributors HOT 4
- What if session scope request id exceed maximum? HOT 21
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wamp-proto.