World: r3wp

Flash might move to RIA (but who's interested to do real apps in 
Flash?) or - many mp3 etc vendors are doing their UI using flash. 
As for html 5, we are still talking vapor, unless it is supported 
by most browsers, which are used by most ppl IE still has 62% of 
share, and IIRC CSS3 and HTML5 are going to be supported in IE9. 
How long do you think will it take to replace those 60% of IEs out 
there by IE9? Well ... I know what you are trying to say ... it is 
inevitable ... but ... not yet, not yet :-) .... this probably belongs 
to advocacy though ....

Flash might move to RIA
 : it's already done, it's called "Flex".

who's interested to do real apps in Flash?
 http://www.adobe.com/products/flex/buzz/customers/list.html

ActionScript, which is Flex's programming language is now in #19 
in Tiobe's index.

Maybe Flash usage for sockets, animations, games and videos might 
start dropping soon, but as an application framework engine, its 
usage keeps raising.

rising

raisin

I used flash as an application framework for an engineering co once.. 
one of the biggest mistakes of my career.

SVN r59 : experimental mod-upload released.  This new mod adds server-side 
API for querying realtime progress info on uploaded files. See the 
demo : http://localhost/upload.html(not commented yet).

Current restrictions:
- works only when posting one file at a time in a given <form>.

- can't make it work for IE (IE seems to have an issue with setTimeout( 
) method).

Help would be appreciated to solve or workaround the setTimeout() 
issue with IE.

If you're testing the upload demo locally, be sure to pick a file 
big enough (at least 10 Mbps). Don't worry about uploaded files, 
the target script (show.rsp) doesn't save them, so the server's copy 
will be deleted as soon as the upload is finished.

This mod-upload version is unsuitable for production yet, the upload 
tokens on server are not garbage-collected.

10 Mbps => 10MB

After updating the SVN, I get a 

 id: 'cannot-open
    arg1: "/c/websock2/Cheyenne/mods/mod-upload.r"

and the file is not there.

should have some default error trapping for socket-apps in the http.cfg 
file, no? One typo brings the whole server down.

Working on some websocket experiments.. 
http://shinyrockets.com/exper.html


- simple canvas game... Losing the game publishes the fail , ip and 
port to everybody.

I'm curious as to lag around the world (should add geocaching i suppose)

Doc, any thoughts on a standard protcol for sockets? xml?

mod-upload: it was missing, it's in the repository now.

standard protocol for sockets : JSON.

take the reb-services dialecting approach and format it in JSON ;-)

Typos errors in config file should be caught, what kind of typo was 
that?

Btw, keep in mind that defining a "standard" protocol above web sockets 
goes against its primary purpose : provide a general purpose packet-oriented 
communication channel. It would be like defining a "standard" protocol 
above TCP.


For practical usage with JS clients, JSON data format is the way 
to go. Don't forget that the web socket implementation in Cheyenne 
is partial, only TEXT frames are supported currently. I could add 
the binary support also, but I don't have a need for that for now. 
If someone has a *real* need for that, let me know.

IE issue fixed with upload.html. It wasn't a settimeout( ) issue, 
it was a IE caching all the AJAX responses.

SVN r61

FEAT: added request/store function to help manage uploaded files 
(see %changelog.txt).
FIX: IE issue with upload.html (cache issue). Works ok in IE now.
DOC: upload API documented in %www/upload.html.

JSON was my first thought.. but I think I'll build a custom "data 
format" using triples to keep inline with the back end.. still thinking 
about it.

I guess the binary support would go hand in hand with your new upload 
script?

There's a blur with websockets.. traditional usage takes a form, 
serialize and send to the server as a associative array in the url.. 
With sockets, that's not necessary. 

Forms are becoming less relevant.. As individual fields can do their 
own thing.. 

<input type="text" onblur="ws.send(this.val());">

Even non-form elements can be used.. 

<p id="myparagraph"  onchange="ws.send(this.text);">
Lorem ipsum
</p>

BTW, the typo wasn't in the config file, but in my ws app,  If one 
app doesn't work, should the whole server come down?

Binary support / upload: these are 2 different things. Uploading 
files (access to local filesystem) still requires FORM with multipart/form-data 
encoding.

Hmm, maybe not with WS?

Might even get away with partial file uploads, incrementals etc.

WS doesn't give you access to local filesystem.

P2P

http://webkit.org/demos/sticky-notes/index.html

Another handy html 5 api..  Web pages can determine if the client 
is online. (returns boolean)

var online = navigator.onLine;
alert(online);

So, jump on a plane, update your Cheyenne data, store local, and 
sync via ws when back online :)

<script>
var online = navigator.onLine
if(online){var conn = new WebSocket("ws://localhost/ws.rsp")}
</script>

else{golocalsql();}

Terry, sure, HTML5 opens up a new world for web applications, the 
gap with native apps is closing.

How about this..  passing a block via websocket as a data method? 
(not even sure if it would work), and loading it?
ie: ws.send("[a 'one' b 'two]");

any security issues?

Not is you screen the data after loading and throw away all functions.

Hmm, that could be very handy.

It requires more security screening than JSON on the server side, 
and more work on the client side.

But, it is rebol friendly

Not for web clients. You have to assume the client is hostile for 
web stuff, and screening REBOL data for malicious stuff is harder 
than parsing JSON data. The only way to be safe is to not transmit 
an executable dialect - full data dialect, reject anything bad.

It's great if the client won't primarily be a browser, as long as 
you stick to full dialects and never DO the code.

Fortunately you can't create reference loops without DO, so if you 
stick to LOAD/all you should be fine.