World: r3wp

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.

I use websockets for passing javascript and JSON to a static page. 
 The pages start off with a single javascript function, then i use 
websockets to lazy load.


Here's  pseudo for an email client using Cy (shorting Cheyenne to 
Cy from C.. keep confusing myself)


- Start with a blank page with the websocket function. No HTML, No 
css.. link to Jquery only  .. this page is under 1k

- Send an initial message to Cy with the page name, Cy responds by 
pushing the necessary HTML (simple email form), CSS and JS (a single 
function to send back the form results to Cy) to the DOM

- User fills out form, and submits.. pushing an array (JSON, string.. 
whatever) with the message details to Cy
- Cy sends the message via rebol mail

... but then 


.. Cy polls the users pop mail acount on a regular basis, and upon 
finding a new message, sends <i> sends a javascript function</i> 
to the page, that gets EVAL 'd . This could do some animation in 
a canvas tag, push some message to the browser's chrome.. whatever.
 

All using the same tiny webpage. When you look at the source, you 
see 20 lines of code.

JQuery is optional, you can lazy load any library you need, whenever 
it's needed.. it's possible to mix and match based on the requirements.

Doc, re Sencha.. i found it pretty smooth on an iPhone, but slow, 
what did you mean? I/O or animations?

Tested on Android only, any action in Sencha demos seem slow (clicking 
buttons, sliding, animations) compared to native UI.