return status from #sendUTF() et al. about websocket-node HOT 10 CLOSED

Yes, I did implement an outgoing queue, but I realized later that the usefulness of this is dubious at best. As it happens, Node implements its own outgoing queue and will send data to the socket as fast as the client can receive it. It will buffer any additional data until the client is ready to receive it, effectively accomplishing exactly the same thing as what I implemented. It's a redundant layer. That's the default behavior when one uses Socket#write() without bothering to check the return value.

I'm planning on doing the next version of WebSocket-Node using a streaming API rather than a message-based API, and will build a compatible message-oriented API on top of that. With a Streaming API in place, it'll be more feasible to directly deal with the send buffer and transmission throttling.

from websocket-node.

Great news. I'm building a messaging server on top of WebSocketServer. You plan to spawn a branch for streaming API?

from websocket-node.

Cool. What kind of messaging server? When I'm ready to begin implementing the next draft and the streaming API along with it, I will create a draft-10 branch to house the current implementation, and then the master branch will continue to be the main development branch.

from websocket-node.

Here we go: https://github.com/dvv/connection -- example/websocket. Please, give some feedback. TIA

from websocket-node.

I didn't see a README on the page, and I'm not quite sure what I'm looking at from a quick glance at the code?

from websocket-node.

right, i'll try to compose a readme. the point is to provide cross-browser bidirectional high level messaging layer with acknowledgments, WebSocket-Node being a server

from websocket-node.

Ok cool. What are the acknowledgments needed for? In case the transport is lost and needs to be re-established?

Sent from my iPhone

On Sep 19, 2011, at 9:15 PM, Vladimir [email protected] wrote:

right, i'll try to compose a readme. the point is to provide cross-browser bidirectional high level messaging layer with acknowledgments, WebSocket-Node being a server

Reply to this email directly or view it on GitHub:
#8 (comment)

from websocket-node.

Drafted a readme: https://github.com/dvv/connection/blob/master/README.md

Acks are the way to use continuation-style programming. Compare:
Fs.readFile('foo', function(err, result) { ... }) and conn.send('foo', argument, function(err, result) { ... }). When remote side is done with message, it can (should, in fact) report this fact to the caller. Connection#ack is a safe way to pass info back to the caller

from websocket-node.

Ah ok, so it's more like an RPC framework over websockets. Nice. Reminds me of dnode: https://github.com/substack/dnode

from websocket-node.

Yes. But without >=6 dependencies and with much cleaner interface, imho ;) I try to compose a transport-unaware browser-server intercommunication channel with messaging.

from websocket-node.