World: r3wp

i know, you're just against being the person to do it: :)

well, as I'm not a jvm nor .net fan, I might not be the right person 
for the job ;-)

I might try with .net thought, the VM is more dynamic languages friendly 
than the jvm.

And there is mono

Isn't mono still lagging behind too much?

in terms of supported features

given the choice, I'd use .net instead of java. the only issue is 
that it relies tooo much on the IDE, which becomes so sluggish on 
complex setups that its not funny.

and neither run on the iPad ...

MS IDEs crash regularly in a typical work session... plus every new 
release, you have to refactor stuff... its just really not nimble.

anyhow... we are pretty OT  ;-)

Is the Da Vinci project still going strong ?? http://openjdk.java.net/projects/mlvm/

long time I haven't looked at Da Vinci...

yes it's OT, I'll stop here ;-)

bottom line... only Cheyenne is being maintained

right

I could do some hotfix to CureCode too if required

but no evolution (for now at least)

There was a wish to add a documentation type to curecode

ah, that could be added easily, I'll try to scan the CC channel here 
to see look for easy changes this weekend.

Just to allow users to add examples of how to use functions etc .. 
since many people do not have access to the various "wiki"s

Doc, the websocket problem discussed earlier seems related to this.. 
http://code.google.com/p/chromium/issues/detail?id=28453

things work fine as long as i use a domain name, but as soon as I 
go localhost:81 or 127.0.0.1:81, it goes south.

It also seems ok if using default port 80..

hmm, now its working fine everyway.. feel free to completely ignore 
my previous noise, and I'll just pretend it was all a bad dream

is there a ws:// protocol implementation for R2? How do I connect 
to a server and use websocket without a browser?

There isn't.

any plan? or is it difficult do you think?

http://www.whatwg.org/specs/web-socket-protocol/


Doesn't look very difficult .. if you need it, start a bounty for 
it

thanks, I'll try.

I had a quick look at the first few pages and it seems to use framing, 
with only one frame type defined at present.

Now Ladislav is the master here having written the beer protocol 
which multiplexes different frames over tcp .. so I'm sure he could 
do this if there are any difficulties.

Thank you. One last question, is the latest binary version of Cheyenne 
support web sockets? or it is the svn version which supports it?

Dunno .. never used web sockets ... Doc??

What uses are people finding for web sockets?

Do you mean people use it for what?

Yes ..

I presume that a web socket "function" will block all of Cheyenne 
until it is completed.

Unless there's a way of handing off to one of the spare cheyenne 
processes

I presume Terry is using web sockets to communicate to cheyenne instead 
of using rsp or cgi

and cheyenne is an embedded web server

well, I'm planning to make an turn based online game, but not inside 
a browser, client will be a separate rebol application. it will be 
connected to a web socket, and player did somthing it will be sent 
to all other players

I can use cgi aswell but there is no way to detect if a player disconnected.

But yes it blocks the whole Cheyenne process so it should be a very 
small and fast function.

Btw, I guess the latest svn version of Cheyenne supports web sockets 
as in changelog.txt which is 0.9.20.
The latest binary version on web site does not, V0.9.19.

How do you know it blocks? Doc explained it doesn't

it says in Cheyenne documents?

the docs say it blocks

See http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/www/ws-apps/ws-test-app.r

As this is running in main process, when

;-- any handler runs, it will block the server, so, you have to keep 
your code

;-- very efficient, it should run in between 1ms and 10ms if you 
want your Cheyenne

;-- server be able to scale to hundreds of concurrent clients. That's 
the cost to

;-- pay for not having multi-threading...Anyway, you can use the 
'do-task function
;-- to run longer code without blocking.

Websocket server code can be run from two places: either in Cheyenne 
main process (allows accessing all clients ports and detecting ports 
open/close events) or in RSP scripts (using 'do-task function from 
a websocket app) when the job takes too much time (like accessing 
a database).