World: r3wp

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

Terry: tested Sensha (Extjs re-branded), looks good but way too slow 
even on a Android with latest hardware (1Ghz CPU)...too bad.

I guess it's only good for desktops with a touch screen, not for 
mobile devices.

So, we could use this to send email instead of RSP script?  Just 
have to upload attachements base 64 encoded still I guess as it is 
still a text protocol

Graham: I don't see the relation between websockets and sending emails...what 
problem are your trying to solve?

I use Cheyenne to send email ... via Rsp

Sounds like I can forgo the sendmail.rsp script which a user might 
damage and just use a web socket instead

Or am I not understanding this correctly

Graham: websocket is just an evolution of the HTTP protocol, it's 
not TCP, you can't contact a SMTP server from a browser directly 
if this is what you have in mind.

AFAIK, websockets is for replacing AJAX.

AJAX will remain in use I guess, having a permanent connection is 
not always required and makes servers less scalable. Websockets will 
mainly replace all COMET tricks for server-side events.

Doc, you have a mail server inside Cheyenne .. .that's what I want 
to use.

Graham: I don't see any advantages in using websockets rather than 
classic requests then? Btw, you can't upload files from a browser 
using websockets AFAIK.

Doc, I have a Rebol app .. that uses Cheyenne as an helper app ... 
so I would be using it from my Rebol app ...

I would just have to use an ws:// protocol ... yet to be written

The possibly advantage is that I don't need an rsp script on the 
user's drive that might get damaged or deleted ..

If you're using Cheyenne just as a MTA, better strip it down to just 
UniServe + MTA service, and integrate %Uniserve/libs/email.r in your 
client app.

I also use it as a web server

for prefilling Acrobat forms ...

If a pdf is loaded into a browser .. it allows one to post the data 
in an acrobat form ... but if it is loaded into acrobat reader alone, 
then it can post, but it can't understand any html returned by the 
web server

Graham, are you using Cheyenne's embedded mode or you're just launching 
Cheyenne's binary?

You could pass a message to C via websockets and have C send it along 
for you.