World: r3wp

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 ...

Here's some prior info on tasks gathered from Carl's replies in September:


The model is: threaded CPU, shared memory, shared symbol space, shared 
system function space, separate evaluation stacks, separate user 
contexts.


Intertask comm is via Ports. Sync is via ports. BTW, "ports" does 
not need to mean "sockets".


The host level can provide a more direct mechanism for inter-task 
sync and comm.

I'm not a fan of locking, but sometimes it's necessary. Otherwise, 
mods can be "cloned" for multi-task uniqueness.

what is the interest of intertask comm if we got shared memory ?

Actually, if i'm not wrong. Tasks are switched every 0.001 second 
(wiich might be too slow for huge task handler, like uniserve).

The only thing missing currently, is the ability to switch tasks 
prior the next switch event.

A RESUME or SWITCH function, could allow that. To switch to the next 
waiting task in the queue immedialty.

On which OS are you testing?

Vista

what is the interest of intertask comm if we got shared memory ?

Shared memory needs coordination to manage the shared access. Intertask 
communication allows tasks to share less, which makes the whole more 
scalable. Plus it can turn into interprocess or intercomputer communication 
without changing algorithms, which makes it even more scalable.

Threading on POSIX is unimplemented. If it works on Windows, it's 
by accident. It's unfinished and untested

Yes, but one of us (not me) can help work on it.