World: r3wp

here is the only websockets demo I found online http://orbited.org/wiki/LiveHelp

here is a flash based websocket so you can support old browsers and 
use websockets now 8-)  http://github.com/gimite/web-socket-js

My demo is ready, but I found an issue to fix first with HTTP keepalive 
connections timeout colliding with web sockets timeout. The demo 
should be ready to try in a couple of hours (lunch time here).

here is jQuery websocket plugin and chat demo that I will try to 
make work with Cheyenne

Midnight here ... I'll check it out tomorrow!

great stuff Dock, btw.. 8-) I hope it can handle huge traffic!

forgot the link.. http://bloga.jp/ws/jq/wsload/s1.htm

Web sockets server-side support code is much shorter than HTTP, so, 
in theory, it should scale higher.

http://www.kegel.com/c10k.html;-P

how many connection do you estimate Uniserve can handle?

here a couple server that supports websockets http://www.tornadoweb.org/
http://orbited.org/http://www.kaazing.com/downloadmaybe there 
is something interesting for you

Don't know, that would require to create some new benchmark tools 
to test the limits. Probably 1000+ opened connections and processing 
100+ messages / sec on a 2Ghz dual core.

REBOL is too slow to hit the c10k wall anyway.

Ah, maybe not with web sockets long-lasting connections...

here is WebKit Web Socket design doc for anyone interested http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh

To pass the c10k wall, we would need to replace the select( ) call 
by one of the other polling methods. That means changing the C network 
layer.

R2 may be too slow, but what about R3 and the C extension Uniserve? 
 maybe you should add a paypal button for us to start supporting 
this future development..

That would certainly boost pure static resource serving speed going 
close to Apache and in some cases, close to Lighttpd, but for the 
RSP scripts, that won't change anything. Only threading could bring 
a good speed boost there.

what is missing in R3 to have Cheyenne working on it? we should make 
sure Carl doesn't forget any feature needed, I sure wouldn't like 
being stuck with R2 because Cheyenne wont run on R3, do you have 
a list that we should relay to BrianH who will relay it to Carl ? 
I know it's still early, but having a plan should help

I mean the current version, not a feature enhanched one.. 8-)

Did looked close enough yet to have an exhaustive list, but probably 
/Library would miss the most.

When R3 features list will stabilize (beta stage), I'll make a more 
complete evaluation of the time required to port Cheyenne (lack of 
/Library can be workaround but will cost a significant amount of 
time).

Did looked => Didn't

SVN r52
FEAT: web socket realtime chat demo added.

FEAT: changed socket application's SEND function specs to SEND client 
[port!] data [string!] (/with removed).

FIX:  timeout web socket issue clashing with HTTP keepalive timeouts. 
Web socket ports are no more timed out after 15sec.

For the chat demo, after upgrading to r52, run the new Cheyenne and 
point Chrome 4 to http://localhost/chat.html.You can try opening 
several windows with different user names to see how all parts react 
in realtime.

ubercool! thank you! 8-))

Seems that the chat demo becomes the standard way to demo web sockets. 
:-)

I'll put the demo online in a few minutes, so we can use it to chat.

Btw, it's my first real try at jQuery, so the code might not follow 
the jQuery best pratices, if some jQuery/JS experts know how to make 
the code more elegant or shorter, let me know.

in the chat protocol, if a user close the browser window, will it 
signal "user quits the room" ? I should try...

Yes, it should.

Btw, the ws:// url still needs to point to a RSP script, but with 
the socket app container, the script doesn't need anymore to physically 
exists.

so in the chat.html example, the url ws://localhost/chat.rsp , instead 
of pointing to /chat.rsp it will look for a ws-app named 'chat , 
correct?

No, the bindind between the URL (/chat.rsp) and the web socket app 
(chat) is done in the httpd.cfg file with the 'socket-app keyword.

Got the chat demo running online. If you have a web socket enabled 
browser (ex: Chrome 4), go visit here : http://demo.cheyenne-server.org:8080/chat.html

damn, this is small stuff.

Posting here the link for the server side of chat app : http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/www/ws-apps/chat.r

Hope this will inspire some of you to ride the new wave of realtime 
web application that will surely start to come this year.

Be back later.

this web chat is using websocket on chrome (and comet in other browser).
http://www.ddmind.com/modules.php?name=gdp_easy_chat

It's a Rebol server and It works pretty well...great uptime and low 
cpu use.

what server is that GDP-Server Alpha (Win32) REBOL ??

here is a quick overview of the rebcomet server:

http://www.screencast.com/users/Perekk/folders/Jing/media/6465c6f2-3c5c-4237-9ce4-0e6d61f74fb1
and 

http://www.screencast.com/users/Perekk/folders/Jing/media/d5c252ef-29dc-4c49-ac10-2ce98cd4518a

it's a server that I'm using in some commercial project, currently 
in alpha stage

is it open source?

I will open source it (and documenting it), when it come out the 
alpha stage.

Currently the dialect is changing every day, so now would be too 
confusing

I would like to replace the tcp http server  with cheyenne.

Now I'm using a modified hipe server by Maarten Koopmans, but it's 
not async, so some things are currently not possible

definitely, use cheyenne ;-)

cheyenne is not only a great server, it's code is pure art, you can 
make it do whatever 8-)

I wrote an article about the new framework on our Syllable sites:

http://web.syllable.org/pages/index.html#id-2010-01-02-22-16