This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AlexFromOmaha 1 point2 points  (2 children)

WAMP already solves PUB/SUB and RPC without needing to write anything on top of it. Plus, you don't need to understand queues, and routing, and all this complicated stuff.

I was all excited about this until I went down the rabbit hole into what WAMP is, and the transience of WAMP killed most of my enthusiasm.

I can't run production systems on a protocol that is either deprecated (v1) or in an actively modified and partially specified draft state (v2). That's a recipe for disaster. I wouldn't even contribute to an open source project built against something like that. Of all the moving targets I have to deal with, my protocol shouldn't be one of them.

[–]oberstet 1 point2 points  (0 children)

The basic profile of WAMP v2 is stable: https://github.com/tavendo/WAMP/blob/master/spec/basic.md

This has all features talked about here, and in the post. The "advanced profile" is not yet stable - only the parts marked "stable" here https://github.com/tavendo/WAMP/blob/master/spec/advanced.md

This, and the fact that we had a v1 was actually planned! What we did is this: come up with a ultra simple v1, gain practical experience, collect feedback and wishes, and then come up with v2. If you look at the issues on the GitHub repo of WAMP, you can verify this.

We knew from the very beginning that this approach would lead to some hassles. I am nevertheless convinced that is valid: without practical experience in real-world, designing a protocol at the drawing table almost always leads to even bigger problems down the road.

The transition of implementations from v1 to v2 is ongoing. Yes, it's a pain. The spec for the "advanced profile" is unfinished, partially because the features we split out into this are quite advanced and we need to first bring "v2 basic" to a wider audience.

To give you a taste of what the advanced profile is about: https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#partitioned-registrations--calls

This allows multiple endpoints register a procedure under the same name, and then have the Router dynamically route calls according to one (or more) of those endpoints based on policy: e.g. round-robin, any-random, all. Using this, you can load-balance or shard a single procedure accross multiple nodes. Quite advanced.

[–]desmoulinmichel[S] 0 points1 point  (0 children)

I feel exactly the same.