Am 16.10.12 11:32, schrieb Eldar Insafutdinov:

On Tue, 16 Oct 2012 07:52:36 +0200, Sönke Ludwig wrote:

Am 10/16/2012 12:46 AM, schrieb Eldar Insafutdinov:

On Mon, 15 Oct 2012 08:53:43 +0200, Sönke Ludwig wrote:

On Sun, 14 Oct 2012 22:45:22 +0200, Eldar Insafutdinov wrote:

I found that there is a module in vibe to handle Websockets upgrade
request and perform handshaking.
However I don't really understand how to then listen for incoming
data on the websocket:
vibe.http.websockets.Websocket class doesn't provide any interface
for that. Is it still a work in progress?

Also looking at the sources of libevent driver I am wondering - won't
websocket be closed immediately after
handling of incoming request:

The vibenotes project
contains a usage example of WebSockets in its broadcast module. It
doesn't seem work as it should though. I'll notify Jan, who did the
WebSocket implementation.

After some digging into why vibenotes example didn't work I figured that
sending a signal wouldn't make it into the other fibers. The reason for
that is that in the processing

for each websocket we check for WebSocket.connected property:

while( socket.connected ) {

However the implementation of WebSocket.connected() checks for
Libevent2TcpConnection.empty property which itself calls leastSize()
method. And this function only returns when there is some new data to
read. So as a result emitting of the signal from each fiber can never
trigger socket.connected to return. As a workaround I made
WebSocket.connected() call TcpConnection.connected instead(for that I
had to downcast Stream to TcpConnection). Is this a correct strategy to
do so?

Sounds reasonable. Closing messages also don't really seem to be handled
in the current implementation, which is probably not a problem in most
situations... but that also needs to be figured out.

It also seems that a Broadcast class should be part of the websocket
module, as user code should never have to use implementation details and
call rawYield(), but thats a different topic.

That's in fact what I'm trying to do - to build a compatible vibe component. has a nice API for real-time messaging, does automatic JSON serialization/deserialization and supports multiple transports as a fallback when Websockets are not available in the browser.

That's actally exactly what we had planned for http.websocket ;) But the time for that was always missing. Being able to use the existing JavaScript side alone definitely is a compelling reason...