World: r3wp

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.

Interesting :-)

I thought node was Python?

FYI: I've implemented the web socket protocol in Cheyenne last night 
(not released yet) but I still need to figure out how to properly 
interface incoming data frames with the RSP engine.

That's really great!

Very cool Doc.

Is there a dummies for web sockets to explain what this does?

It's the evolutionary endpoint of Comet. It throws in special server 
and client support to enable them to keep an open, stateful connection, 
by switching an HTTP connection to what is effectively a lower level 
TCP connection

So it creates a bidirectional channel with only one connection, with 
good chances of penetrating firewalls

Cleans up the mess of the collection of hacks that is Comet

What's the reason why it should be able to penetrate firewalls?

Not familiar with Comet .. except as the name of my dog :)

So, if it opens a stateful connection, then I guess it is less able 
to scale to lots of users

And are people then running BEEP over web sockets?

It opens up the possibility to do similar things, yes, while still 
being able to fool firewalls

It has a good chance of fooling the firewalls because it starts as 
a normal HTTP connection

Since it's being standardised as web technology, there will be a 
big social barrier for firewalls to start blocking it

As a continuous connection, it's less scalable than regular HTTP, 
yes, but it's more scalable than Comet, which needs two connections 
for bidirectional communication, and other hacks

It scales better, as only a single connection is used.. in fact, 
Google is pushing it with Chrome for that very reason.

Comet is a diverse collection of hacks to create longer-term connections 
with Ajax

after the initial http handshake, there's no http headers included