World: r3wp

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.

I have added a few lines to embed-demo.r to show you how to prepare 
it for encapping with Cheyenne running in embedded mode: 
http://code.google.com/p/cheyenne-server/source/detail?r=161

At line 147, you should read "Comment the following line..." instead 
of "Comment this line..." (fixed in r162).

Fantastic! Thanks a lot Doc! Now I can make show to my manager for 
our next project :)

I think it is also possible to include mod-embed.r file. Currently 
embed-demo.exe requires mods/mod-embed.r file (probably the other 
mods as well)

You don't need to include any Cheyenne own files, %cheyenne.r takes 
care about all the required dependencies when encapping.

I did not yet test but with this way we can easily write a websocket 
test server application.

So, mod-embed.r should be external anyway?

I don't understand what you mean by "external" there?

websocket test server application

: you already have it, just run cheyenne.exe and start writing your 
websocket app.

Btw, the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne. If you want to make a GUI app 
in View for just a few simple interaction with Cheyenne, you can 
just #include your View code in %cheyenne.r.

I don't understand what you mean by 

external" there?" when I copy embed-demo.exe alone to outside cheyenne 
directory, it gives an error like "cannot find the file mods/mod-embed.r". 
So even encapped it requires that file and probably the other modules 
(.r) files.


What I was thinking, when I use embed mode and encap the cheyenne, 
it already includes necessary mod files into encapped exe.

Strange, all the dependent files should be encapped in the executable. 
Testing locally...

Here is the error:
make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/Documents and Settings/endo/mods/mod-embed.r"
    arg2: none
    arg3: none
    near: [do any [get-cache file file]]
    where: 'do-cache
]

Ok, I can reproduce it. The module is missing from the Cheyenne package 
list in %cheyenne.r

I see, so its only for mod-embed.r not for other mods I think.

It was left out because I never tested encapping in embedded mode.

I pushed a fix in the repo.

Ok, great. Let me test..

Do not forget to run Cheyenne once after update your files to refresh 
the cache.efs file.

update => updating