6 ms·

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

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.

oberstet 11y ago
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.
fenesiistvan 11y ago
Maybe web developers are not comfortable with the basics?
wolframhempel 11y ago
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/ http://deepstream.io/ or https://www.firebase.com/ 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
- fenesiistvan 11y ago
  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
  - neomantra 11y ago
    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.
neomantra 11y ago
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.
- fenesiistvan 11y ago
  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)
rektide 11y ago
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 https://github.com/crossbario/crossbar

oberstet 11y ago

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.

fenesiistvan 11y ago

Maybe web developers are not comfortable with the basics?

wolframhempel 11y ago

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/ http://deepstream.io/ or https://www.firebase.com/ 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

fenesiistvan 11y ago
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
- neomantra 11y ago
  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.

neomantra 11y ago

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.

fenesiistvan 11y ago
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)

rektide 11y ago

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 https://github.com/crossbario/crossbar