World: r3wp

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

Can it be solved by calling a routine from a dynamic linked library?

Yes, but in Cheyenne context, having to maintain a cross-platform 
C lib to that would be really annoying. It would be the end of Cheyenne 
as a one-file server. Also, it wouldn't run on Core anymore.

to that
 = "for that"

Make the C lib open source and let people, who want that functionality, 
maintain the lib. It shouldn't necessarily be your job.

In the end, the burden will fall on my shoulders if I want fixes 
and updates to be done in time (as usual). If someone makes such 
lib (just 3 lines of C, btw), maintains it (means provide binaries 
for target platforms), I can add an optional loader in Cheyenne to 
use it when present. As for myself, I prefer to switch to Red asap.

I have pushed a preliminary implementation of the latest websocket 
RFC to Cheyenne SVN repo. It works only for text messages of size 
< 126 bytes. I will get back to it in the next day and complete it.

Good luck with your presentation

Thanks, I'll publish my slides tomorrow afternoon on Cheyenne's site.

when I encap embed-demo.r, embed-demo.exe gives this error:

** Script Error: select expected series argument of type: series 
object port
** Where: get-cache
** Near: select cache file


Do I need to do something else? I uncommented "embed" in httpd.cfg.

Did anyone tried Cheyenne in embeded mode?

I am not sure I have ever tested encapping Cheyenne in embedded mode. 
I will test that this weekend, I will anyway spend some hours to 
complete the new websockets implementation.

Don't know if this has been discussed before, but have you looked 
into SPDY?

Not recently, but yes.

Excellent work on Cheyenne, Doc! The structure is mostly excellent 
for what I am doing.

I'm glad it's useful to someone. :-)

One thing I need to do is add encrypted script files. What do you 
think would be the most logical method, modifying source or making 
my own interpreter?

You mean you need to encrypt RSP files?

or just includes is fine

I guess yo would need to modify the RSP engine for that. The easiest 
way would probably be to create a custom 'include function able to 
decrypt your files.

Sounds easy enough.

I think that the cleanest way would be then to extend the existing 
INCLUDE function in RSP.r by adding a refinement (/with or /options) 
and use it to pass additional custom data to the INCLUDE function 
(like a 'decrypt word, followed by a key).

got it. thanks!

You would also need to patch the engine/add-file method where the 
RSP scripts are really loaded.

patch it to do what?

You could add a property to ENGINE object for controlling how files 
are loaded, and set/unset it depending on INCLUDE refinement.

Loading and compilation of RSP scripts are done in ENGINE object, 
not by INCLUDE.

INCLUDE is just the user API front-end.

I see it now.

Where do I find engine?

In handlers/RSP.r

I ended up replacing the read with one that determines if its encrypted 
by the filename. Decrypts rsp or includes. Works nice. Thanks for 
helping get started on that.

about encap: I'll try to find the problem and if it's not difficult 
I try to fix it as well. I wanted to ask before spending time on 
it. Thank you. Doc: if you already done / test it please let me know. 
I'm planning to use it in a production.

I'll do a quick test on that just after finishing the websocket implementation.

Should be in a an hour or two.

Did the presentation to php audience already happen? What was the 
recpetion of Cheyenne?

See: http://cheyenne-server.org/blog.rsp?view=29

Btw, a RSS feed is available for the Cheyenne blog.

There was about 25 people in the audience, a lot moved to other, 
more PHP-focused, conferences at the same time.

Some were very interested by a simple, small and easily deployed 
web server that could run PHP code efficiently.

Websocket support updated to hybi-10 revision. Websocket chat demo 
also upgraded: http://demo.cheyenne-server.org:8080/chat.html

You would need at least one of these browser to use the new websockets 
support: Chrome 14, FF 8 or IE 10.

Janko: I have extended AUTH to be able to return an HTTP code in 
revision 157:


FEAT: AUTH config keyword can now take an optional second parameter 
(HTTP code 4xx or 5xx) that will be returned to client instead of 
a redirection to the login URL.

The first parameter (a URL) is mandatory and should point to the 
resource where login happens (it's a pass-thru, every other URL will 
be redirected or will return a custom HTTP code, if specified).

Chat demo works with Firefox 8.0.1 on Linux

Thanks for testing.

Endo: I have pushed a few fixes for regressions in embedded mode 
support. I'm now looking into the possibility of encapping it that 
mode.

Thank you. I'll test tomorrow morning.

encapped embed-demo.exe application gives the following error:

** Script Error: select expected series argument of type: series 
object port
** Where: get-cache
** Near: select cache file

I tested on WinXP Pro SP3. Same error as in r151.