World: r3wp

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

Here's a good primer

http://www.indicthreads.com/3625/html-5-websocket-cracks-the-http-request-response-barrier/

i still need to figure out how to interface incoming data frames 
with the RSP engine

That's where my Cheyenne websockets attempts hit the fan. Not so 
much the RSP, buf from a tcp socket to http and back again.

SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.

You'll need Chrome 4 to be able to use web sockets (don't know about 
other browsers).

Currently, your web socket URL must point to an existing RSP script 
(or a path that translates to a RSP file). The included %ws.rsp script 
is just a simple echo service.

Once connected, all the web socket traffic is directed to the starting 
RSP script, where you can implement your own application specific 
protocol and action dispatching while benefiting from the RSP webapps 
features (like the webapp filesystem structure with private/public 
folders).

Server-side 'connect and 'close sockets events are missing. Not sure 
how easy it will be to add them to the RSP application model. More 
generaly, the web sockets require a shift in the whole application 
model, the RSP engine is tuned to request/response model, not client/server. 
I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).

Just think about how a minimalistic multi-user chat app could be 
built using web sockets. The application code needs to be able to 
access all the existing connected sockets to broadcast user posts, 
but these sockets are connected to the main process (UniServe) while 
the application code is run in worker processes...Having everything 
in one process would solve that but you can't run any scalable app 
with such model (beyong just passing messages between sockets). That's 
where mutlti-threading would have been useful...