World: r3wp

But indeed this seems to be lost on Internet protocols

http uses data size

Jetty jumps on the websocket bandwagon

http://ajaxian.com/archives/jetty-introduces-websocket-support-relunctantly

Cheyenne as a "Kaazing Killer" makes it to #3 on Google :)

Hehe :-)

Looks like I'm not the only one ranting about web sockets protocol 
specifications : http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

To get the websocket demo  working am I accessing "ws://localhost/ws.html"?


Using http:// does not work but ws:// redirects me to google search 
of url


I'm using the latest svn version...starting from icon...using chrome 
4

If Chyenne is running on port 80, then 

http://localhost/ws.html

and you should see a javascript button

If you're not running on port 80, then you need to modify the ws.html 
file and add the port number in the ws://localhost part ...

Anyone got an example of how to connect to the web socket from a 
rebol client?

You'd need to implement the client side protocol in REBOL

I'm on port 80 ...


I see the button and get the hello world message popup as well as 
a "comm opened" popup at start...


I was trying to get Terry's demo to work but his "Drag this" does 
not seem to do anything...

Anyone try out Terry's?

Also could not get  ws.rsp to work..."page cannot be displayed"

ws.rsp script is supposed to be accessed only through web sockets 
: ws://localhost/ws.rsp

I get redirected to google search with > ws://localhost/ws.rsp

This URL is not be typed in your browser address, it's for the web 
socket object creation in javascript. Please, have a look in %www/ws.html.

browser address <field>

doh...thanks will have a look.

With my demo, when you click the "Make draggable" button, it sends 
a message to Cheyenne via the websocket.. the response is some JS 
that makes the box draggable.

Doc.. any more thoughts on the ws:// protocol system? As it sits 
now, it's a glorified AJAX call.

It keeps the connection open, doesn't it?

the connection is open, but RSP is stateless

Hm, yes, as Doc said, the server model needs to change

hey doc.. one issue with a forever loop is the ability to listen 
for new incoming messages from the client.. How would you handle 
that? Put them in a buffer, and check it during the loop?

Does Cheyenne have equivalents of Apache's mod_expires and mod_deflate?

It does compression, in any case

It's more the expiry dates for jpeg files that I'm worried about 
at the moment.

Terry, I can't get the box to drag..

It won't drag unless the ws.rsp page does more than just echo stuff 
..

you require my updated ws.rsp file.. see above.

Not sure to understand what you mean Terry, ws.rsp is receiving all 
the incoming messages.

Anyway, I'm working on a improved framework being able to handle 
connect/deconnect client events and giving access to all client ports 
connected to a given ws:// URL.

the connection is open, but RSP is stateless

 If you want to make it stateful, just store the data in session, 
 file, database, whatever...Most of RSP API is still working with 
 web sockets (response object methods will have no effect).

This is what I'm looking to do.

- A client connects via websocket.

- Client sends message "a". The server runs the following

forever[
n: read http://cheyenne-server.org/blog.rsp
prin n
wait 1
]
 
- Client sends second message "b". The server runs the following

forever[
x: read http://rebol.com/cgi-bin/blog.r
prin n
wait 2
]

These loops should be non-blocking.

- ws:// and wss:// need to be  Uniserve services

- the service should simply receive incoming messages and pass on 
to a non-blocking handler, and receive repsonses (optional) to pass 
back to the client
- a method to "access to all client ports" as you mentioned

Terry, got drag working..very cool

Alan, it's rather trivial to track the position of the box relative 
to the screen, and pass that on via the websocket. 

Something like a live chessboard could be created in 20 lines of 
javascript (using JQuery lib)

Terry, in the ws framework I'm working on, there will be a timer 
system with an on-timer handler that you can use for server-side 
events (timer ticks are produced by my scheduler library http://softinnov.org/rebol/scheduler.shtml
recently integrated in Cheyenne).

well, is that not the time to carry on R3, Doc ?
You can use tasks advantageously for such job.

btw what is missing in R3 that you can't carry on Cheyenne ?

Stability (still alpha), feature-completeness (at least R2 level, 
including /library) and last but not least, time and money.

Doc, the scheduler dialect is great. Wonder why it wasn't thought 
of before.
I was considering purchasing a copy of nnCron this week.

I didn't knew that R3 tasks support was finished?

Didn't know either, but i tried some days ago and it works

Terry: I've asked myself the same question while implementing this 
scheduler lib this summer, I couldn't believe that no one did it 
before in ten years...that the bad side of having a micro-community 
(one of the good side is not seeing guys like Ratio popping up too 
often).

Yeah, it's Rebol's primary failing... lack of community size. Same 
reason i switched from Mootools JS lib to JQuery.

Steeve: what works? Launching a task? That's not enough, we need, 
at least, a way to control tasks execution and a safe & efficient 
mean to share values...Unless I've missed something, it's still not 
usable.

AFAIU but I might not have the latest news, Carl postponed full tasking 
support to R3.1, so there's still time.

The list for 3.0 is not final. What I don't like even more is kind 
of lack of leadership. I described it in my marketing related docs. 
There is some kind of imo wrong attitude towards finishing beta - 
some things were moved into "it might be delivered by community" 
category, and it as well might mean - never delivered ...

http://www.rebol.net/wiki/What_makes_a_good_beta#Wrong_attitude_towards_finishind_R3.3F

I'll find what Carl said about task! .... I agree with Doc, that 
it is far from finished ...