World: r3wp

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.

@Graham: you are using web sockets for a wierd job. The shortest 
explanaiton for web socket is: it is the way to trigger an event 
on the client side from the server side via already open tcp (http) 
connection. ofcourse that connection is full duplex, client and server 
both can send a utf8 encoded (currently no binary) string messages 
anytime.

Doc, yes ... launching Cheyenne binary.

The other possible advantage may be that the mta might communicate 
back to me if the mail send fails?  Otherwise i have to read that 
data somewhere?

You can query Cheyenne's MTA (through RSP scrip) for email sending 
job status.

Sure .. just wondering if it's easier to do thru web ports and if 
the server can notify me thru an open port when it succeeds or fails 
rather than me poll the server

I wonder if this is a way to ask Cheyenne to unload it self ... I 
presume 'quit does not work in RSP scripts

Notification thru websocket port: sure, you can have that, but you'll 
need: a ws client for REBOL, a websocket app and a RSP script for 
that (the websocket app will need a timer to trigger queries on a 
RSP script to get the email status or hack in local MTA data to get 
the info to avoid querying a RSP script).

Doc, check out this link

http://blog.sproutcore.com/post/531215199/introducing-sproutcore-touch

fyi html5 has a new file api.. 
http://dailyjs.com/2009/11/30/html5-file-api/

Since the File API is asynchronous, files could be loaded and processed 
in the background while the user does other things. This could also 
be useful for creating web applications that work offline.

File Api Demo (requires firefox)
http://html5demos.com/file-api

If you haven't yet, check out http://lesscss.org/

Or look here if you want to code in something other than Ruby, PHP 
or .NET: http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/

And it's supposed to be 40x faster too, since the processing is done 
client-side.

Yeah, was looking for the JS link (not on their main site?)

<i>This</i> is the kind of thing I'm talking about when I say "less 
language, more tools".
There's basically ZILCH of this sort of thing in Rebol.

I mean, if this doesn't have Rebol dialect written all over it, what 
does?

less.watch() is pretty cool