World: r3wp

It seems js.io is an alternative to web sockets. If it's true that 
web sockets need native browser support just like the server side, 
Comet will still have a long life

Janko: "About code loading on on-page-start : yes I know of that, 
I am using it as dev setup so I know latest code is reloaded each 
pageload." 


There's an easier solution for that: add -w 0 argument to Cheyenne's 
command line, this will ensure that the worker process will be reloaded 
for each new request. Here's the command line I use to run Cheyenne 
on my development boxes : C:\Dev\SDK\tools\rebcmdview.exe -s cheyenne.r 
-vv -w 0

Kaj, "long life" is a relative term.  I suppose it depends on the 
service. If i build a service that lets you access my killer app, 
but say "you need to use Chrome" then 'long life'  may be irrelevant.

To you, but Comet will live happily ever after. :-) Anyway, I know 
what you mean

The point is that there can be no killer app targeting just a few 
percent of the market

Still, I'm now considering the same as you. If I bundle Chrome with 
Syllable, by the time I am progressing with a few web apps, web sockets 
may have penetrated far enough to not bother with Comet

I've got this really odd situation ... I have Cheyenne and the rebol 
micro web server both running.  Cheyenne is on 8002, and MWS on 8001.
Both share the www directory.

at times I access a file and I get a 404 from Cheyenne but the MWS 
can find the file!

It's as though Cheyenne is looking elsewhere ...

my httpd.cfg root-dir is pointing correctly to the right directory, 
and I have an exception for cheyenne.exe in the windows firewall.

I never saw this issue under Window XP, or Vista and I'm running 
on Windows 7 Professional.

Looks like my application is writing files to a hidden directory 
somewhere which the MWS can see, but Cheyenne can't see.

Must be some type of windows redirection

or UAC virtualization

So, not a Cheyenne issue ...

Cheyenne is looking in the right place,  but my app writes are being 
redirected somewhere else.

Found a cool example for future Cheyenne web sockets : http://www.onlinegames.com/basketball/

i'm bad at this Game

Did you created a group Dock ? perhaps i can beat you

Graham, maybe that's Windows security thinking it knows better than 
you, like Vista eating AltME's files?

The nice part is playing live against ~2000 other players (with realtime 
classification between players).

My best score is 120.

Wow, you're good

stucked at 1000 more or less

I'm not even in the top 100. ;-)

Rebol group
http://www.onlinegames.com/basketball/?2oisqn74tz

Won't work on Linux

Steeve: "Due to server load private Group Contests have temporarily 
been disabled (sorry)"

Graham: I've upgraded Cheyenne in SVN with an improved logging of 
translated filename from URL. That should help you see what's going 
wrong.

349

That should make you the winner. :-)

Was that your score or your position?

score

Then you've earned the cup!

i mean, position in the last game

my best position

Doc .. thanks

did anyone try the cache service? any suggestions? http://reboot.ch/rebol/cache.r

SVN: Can someone give me a short note how to best get the SVN version 
into a "production environment"? Is it one file I can just run on 
the server? Or do I need to build it myself somehow?

What's it best used for?

Just use a svn client to download the repository, run the source 
version once, and then encap it.

SVN r44 - FIX: same webapp virtual name can now be used in different 
virtual hosts.

This should fix the issue raised by Janko.

Using Cheyenne and websockets as a backend to Flash, Silverlight 
etc would have it's merits as well.

If there's one thing I always have running on my monitor, it's the 
browser. I don't see much need for another GUI, including /view

I can envision a day when everything will have an "always on" connection 
with everything else that is important.. probably via websockets. 
 ie: my email, chats, voicemails pushed to me wherever i am, and 
on whatever device. The ability to do this is nothing new (SOAP, 
XML-RPC etc), but what is missing is a homogenous catalyst... the 
webserver seems the most likely candidate, as they are the de-facto 
interface to the world's DBs. This is my vision for Cheyenne, that 
of an Uber-server.

Oh, and LFReD driving Cheyenne's business logic :)

Hey Doc, have you seen Node?
http://nodejs.org/#about

I looked at Node a few days ago, interesting choice to see JS at 
server-side. I guess that the included 8k lines of C code help a 
lot having a decent speed. ;-)

Isn't that the included V8 VM?

From Node's sources, no trace of V8 VM, it's the Node network and 
event engine that's built in C for the most part.

It's like if the whole Cheyenne low-level layer (UniServe) was 100% 
built in C.