World: r3wp

H: cool. Cheyenne.

G: all.

My site on EC2 is private .. http://gchiu.no-ip.biz:8000/

Henrik: nice!

I'm hosting 5 virtual sites on mine using Cheyenne ...

Carl, all I can say is that I've had much fewer connection dropouts 
with my Linode than what I observe through AltME. It may not reflect 
your situation, but it just looks far more stable to me. Also you 
can specify where you want your server placed, and so have multiple 
accounts in different physical locations.

H: This AltME world runs from a different provider (via rebol.net), 
so is not typical.

Dockimbel, yep, nice and stable. Love it.

I'd be quite interested in testing R3 Chat on Cheyenne. Right now, 
it must drive the rebol.net server crazy on CGI.

(It pipes all R3 Chat connections via a CGI proxy.)

Amazon charge only for uptime .. at 8c an hour.

So, you can test for a couple of hours and then quit.  Want to run 
a windows 2003 or 2008 server to test?  Start them up and pay 12 
c an h our.

CGI proxy? They still make that stuff ;)

Much more flexible I suspect than Linode or Slicehost

but costs a little more.

T: yep. Blast from the past.

Hey, its 2010.. where's my flying car they promised back in the 60's?

Carl, you have any thoughts on websockets?

With linode you can actually do fancy multi-host redundancy stuff 
or auto reboot on some conditions, etc.  their control panel is also 
extremely well made.  you can setup your server (out a good variety 
of POSIX OSes) in a matter of minutes.

I am using both, slicehost and linode since a year now.
very good virtualisation with both of them. flash, mysql 
very stable, even a big mysql-server with only 384mb ram 
is running fine. linode has a better control panel, 
slicehost feels a little faster.

there is also another candidate for virt-hosting. 
gandi, located in france if somebody likes europe :-)
scalable via virt-shares.

https://www.gandi.net/hosting

Amazon allows you free db storage in multiple redundant locations

Speaking of threads.. Along with Websockets, HTML 5 comes with Webworkers 
(supported by Chrome as well)


Workers provide a simple means for web content to run scripts in 
background threads.  Once created, a worker can send messages to 
the spawning task by posting messages to an event handler specified 
by the creator.
The worker thread can perform tasks without interfering 
with the user interface.  In addition, they can perform I/O using 
XMLHttpRequest (although the responseXML and channel attributes are 
always null).
The Worker interface spawns real OS-level threads, 
and concurrency can cause interesting effects in your code if you 
aren't careful.

https://developer.mozilla.org/En/Using_web_workers

Here's a great webworker article / demo
http://blog.mozbox.org/post/2009/04/10/Web-Workers-in-action

that is nice!

Need to try an experiment where a worker thread sends an AJAX request 
to an RSP page, which in turns pushes back via websocket :)

Hmm, maybe Chrome 4 isn't there yet after all?

Nope, wrong again.. workers are fine in Chrome.. that last demo only 
works with FF

Here's some other demos on Resig's page  
http://ejohn.org/blog/web-workers/

Here's some code that uses flash as a websocket proxy for browsers 
that don't support websockets
http://github.com/gimite/web-socket-js

Needs some tweaking, particularly with ports.

Demo.. pushing sound to all ports

http://shinyrockets.com/echo.html

Uses the HTML 5 <audio> tag.  Non-blocking. Open up 4 or 5 tabs and 
you get a flock :)

Not getting any sound, Terry..

using chrome4

hmm

works fine here.

can you get this? 
http://upload.wikimedia.org/wikipedia/commons/3/39/Brummdose.ogg

yes

Did you click the button?

yes

there ya go

i can hear it :)

Still no sound...even when clicking the button

it's playing here when you click it

volume up.. all that stuff?

thats weird

yes

I guess you can check out the 'console' after hitting CTRL - SHIFT 
- i   .. check for errors

I just found out about a bug I was making and could only be discovered 
when cheyenne was first started, because some word was undefined 
then so it triggered an error, if I did some other things I couldn't 
see it but it would return wrong information in reality .. 


1. is there any way maybe that would make cheyenne "reset" each request 
(for debugging & testing purposes, not production) .. the -w option 
seems not to do this. 


this could probebly be solved by wrapping also those parts in functions 
... another question..


2. Is there any way I could see all globals I created so I could 
find wtich ones I "leaked" unintentionally .. 


it would be very helpfull if rebol could let you define functs that 
would warn you if you used or defined any global words

one solution is also that I define all words local to pageload in 
some object that is cleared on each pageload probably

1) I use -w 0 daily, works ok here.
2) see the solution in Core group.

Btw, since 0.9.19, the RSP engine tries to catch all words defined 
in RSP scripts but outside of a local context in a hidden webapp 
context (one per worker process).

1) I tried -w before (I remembered you hinted me the last time to 
use it to always reload) but it didn't make the difference in this 
case (as far as I can tell).. does -w only work with source discributtions?