WAMP – The Web Application Messaging Protocol | Hacker News Reader

WAMP – The Web Application Messaging Protocol

wamp.ws

56 pointsxg1536 comments

WAMP usually means the "Windows, Apache, MySQL, PHP" stack. So creating a new "web technology" with the same abbreviation is a bit stupid. Your going to have a bad time getting search working.

Though I do agree with the general sentiment of your comment, I should point out that the maintainers of this project do address this issue in their FAQ[0].

[0] http://wamp.ws/faq/#naming

Wow. You can't just... use the same acronym and assume everything is hunky dory because you pronounce it differently. It's still the same damn letters! This project should have gone with "WebMP" or the full WAMPWS acronym.

By "stealing" an existing, long-running and popular acronym, the maintainers are going to stifle this project no matter how much they try to separate themselves from WAMP.

Trick question: is it possible to run WAMP on WAMP?

You know when you have to create a separate section just to explain your name that is the time you realize maybe this was not such a good idea.

> Because of this potential ambiguity, here is what we recommend for authors/implementors

Potential ambiguity? It's nothing but ambiguity! What were they thinking.

Good point, however I wouldn't consider this stack (Windows, Apache, MySQL and PHP) a huge rival for future in terms of growing number of search engine results.

Maybe not in the startup world, but because of the popularity of LAMP and the ubiquity of Windows, a lot of people use WAMP (e.g. via XAMPP) as a local development stack.

It's important to be aware of our own cognitive biases: while Linux is the de-facto standard on the server side and the startup scene is dominated by MBPs and its variants (with a good helping of Linux again, though often in VMs), this only represents a tiny fraction of developers. Dark Matter Developers are a thing.

WAMP has been a thing since 2003, with over 12 years of history.

It is the predominant Windows PHP development environment and Apache stack - that has millions of users worldwide.

A quick test searching for "WAMP protocol" works just fine (wamp.ws is the #1 result) and isn't too hard to type. Without "protocol" the OP site drops to #4.

I did not log out of the Google mothership so perhaps my results are skewed, but I also haven't heard of the WAMP protocol before. :)

> WAMP usually means the "Windows, Apache, MySQL, PHP" stack

Ya, but no one in their right mind runs that.

All the more reason to avoid the acronym, then; the people who are stuck with it need all the help they can get.

> WAMP usually means the "Windows, Apache, MySQL, PHP" stack.

The solution is simple: Wait for everyone to replace MySQL with its non-Oracle clone, MariaDB. See? Easy!

Or maybe they'll go the NoSQL route and use MongoDB.

I've been forced to use this on a contracting-job and not exactly happy with the state of the current components. It's a bit too brittle, there's usually little to no documentation on the different authmethods between different components (MDWamp and AutobahnJS specifically). There's sloppy typo's and every few hours the server decides not to accept connections for a certain auth-id anymore until it is rebooted.

Regarding docs, yes agreed. But we are working on this and things are improving. This is still moving fast .

Rgd the server stability issues you mention: what WAMP router are you using?

While WAMP is awesome on the paper. (And it is definitely awesome.)

Some disclaimer would be fair. Currently, the most complete router implementation is Crossbar.io (Python), while it is functional, documentation is lacking cruelly. For example, we don't know yet how to do proper cookie authentication. Or the WAMP-CRA authentication has a little flaw and should be replaced with a new auth scheme.

Another example is that AutobahnPython or AutobahnJS are lacking documentation on CallOptions or SubscribeOptions and other things. There is a lot of boilerplate to achieve simple things like... managing a connection lifetime (there is onopen, onclose, and onclose gives you some details, but no consistent, it's hard to know when auth failed or connection aborted).

Anyway. It just means that WAMP is in his debuts, I hate some weaknesses of the WAMP ecosystem (documentation, boilerplate, etc...) Nevertheless, it's awesome and you should definitely try something with. And if you can, contribute and make it incredible.

(No offense, I'm a fond of WAMP, but I don't want people to say things that are obvious like: "oh there is no doc it's a shitty project" -- WAMP is moving fast. Very fast.)

Can somebody elaborate why the need for such libraries, when:

-client side websocket handling is ~3 lines of code

-server side websocket is ~200 lines of code even with pure bit level C/C++ on top of any TCP socket (the websocket RFC is very simple)

-writing a simple protocol for yourself is obvious

So, you can write all these for yourself within one day and then you know all the details. It takes more time to study how to use others code and you will still remain on the wrong path if some modification would be needed, feature missing or you have to fix a bug.

The need for such a protocol is to promote interoperable serviecs. Websockets just sends data around, but with protocols like WAMP it's possible to build routers like Crossbar.io[1], where a bunch of backend services can talk to a front-end box that communicates with clients; it's the Vulcand (a HTTP message router) of WAMP world.

And that's the thing... websockets is terribly un-web: it doesn't talk about resources, with addresses, it's a glaringly ambiguous pipe that could have anything. Forming a websocket does do a content-negotiation pass, but there's nearly no concensus for what to expect. And this is an early contendor trying to give Websockets well known content forms to talk. Not just well known, but resourceful, addressed content too. Whereas with HTTP, we've had a long long history of creating interactable public APIs, this is something WAMP has to create, because Websockets is anti-web.

[1] https://github.com/crossbario/crossbar

Reconsider your statement, replacing "WebSocket" with "TCP socket". Why do so many networking and messaging libraries exist when you can communicate with another socket endpoint in a few lines of code?

This specification describes two common network design patterns (RPC, PubSub) and establishes a reusable heterogeneous framework for using them. If somebody needs those patterns, they can just pick this up and use it, and also interoperate with other clients/routers that use the same specification. Since there is this implementation-agnostic specification, client APIs and routers can be implemented within whatever language and context (embedded system, server, web browser, whatever) and they will all work together.

The WebSocket is a transport. One can put many sorts of subprotocols over it and this is one effort to make a common , useful one.

It takes a lot of time to implements fast/robust/scalable sockets. However this is not true with websockets. With websocket you don't have to play with various models, OS API's and threading. You just have to interpret/format the received/sent bytes as described in the RFC. Of course, you can put any app logic over websocket, but this has less to do with the websocket itself (then we enter the word of "app servers" for which we have endless other solutions if somebody favors a certain framework)

More complex realtime applications can benefit from higher level concepts like data-sync (observable objects that share state between clients), e.g. http://deepstream.io/ or https://www.firebase.com/ or more complex routing strategies, e.g. AMQP exchanges. A great example of the impact of this kind of standardized protocol / architecture on top of a low level protocol would be REST on top of HTTP

Ok, but then why the focus on the "websocket" which is just a simple protocol over TCP. Why not an "universal" app server which can handle also other transport layers. We already have these kind of frameworks (and "websocket" is just a single line on their endless feature list)

Edit: anyway, i see where this module would fit, i was just curious why we need to use for everything a foreign component and create more dependencies for our projects instead of developing in-house such trivial modules

The specification says the WebSocket is the default transport; some implementations also support Unix Sockets and Unix Pipes.

I have my own in-house WebSocket (raw, not WAMP.ws) application server and a very thin client-side API wrapper around raw WebSockets; it performs PubSub and some RPC. It's not rocket science but it's also not trivial.

I might consider migrating that custom subprotocol to this framework. It looks like they have thought carefully about the general issues with PubSub/RPC and it will be easier to scale my use (as in expanding my RPC APIs, not in terms of # of clients). I can focus on my data and APIs, not on the substrate.

Hopefully an ecosystem of designers/implementors/users emerges that make this thing awesome. Of course, I've thought that about other libraries and frameworks and it went nowhere, so we'll see.

Minor, but still: you can't write a conforming WebSocket client in 3 lines of code, and you can't write a conforming WebSocket server in 200 lines of code. I know: I have written a couple. Anyway. Moot, since this isn't about WebSocket.

WebSocket only provides you with a bidirectional message channel. It's low-level, and does not provide application messaging.

WAMP can run _over_ WebSocket, but also other message channels. E.g. you can have WAMP running over a shared-memory message queue.

Maybe web developers are not comfortable with the basics?

Might have misinterpreted this, but from reading all the slides - it seems that even for RPC, you have to pass all messages via a central server.

For use internally between services, this seems like a really bad idea. Seems like it'd be a big bottleneck when it came to scaling.

No, you're right. Multi-node support is on the roadmap, but no ETA yet. Until that's implemented I can't seriously consider it for production.

I love the concept, though. One unified layered for all your services.

I'm unclear why the root node of WAMP messages is a JSON Array.

The rationalization for verbose, weird, ambiguous formats like XML and JSON is that they're "self-describing".

Might as well just use MSGPACK or something.

WAMP can use different serialization formats, and MsgPack is one of them.

I read this as "Winamp" and I had a flood of nostalgia.

The good ole' days.

I read this as "WAMP" and I had a flood of bad memories.

It really whips the llama's ass!

I'm using deepstream.io for a project and it works well so far. It has some extra features like distribuited RPC calls, realtime search provider and transforming outgoing data.

So this is an alternative to hook.io?

In a way yes, but WAMP offer more functionality (e.g. PubSub)

and also socket.io?

socket.io is a JS point solution for PubSub only .. http://wamp.ws/compared/#socketio

Reply on news.ycombinator.com