World: r3wp

Here's the configuration I'm using for CureCode.org :
       webapp [
                virtual-root "/rebol3/"
                root-dir %/home/curecode.org/rebol3/
                locales-dir %private/locales/
        ]

%private is located under %rebol3/

aha, thanks :) I will try that way

Btw, %private/ folder under a webapp folder is a *special* folder 
that's protected from direct access (you'll get 404 if you try), 
so you can safely store there your libs and support code.

aha, good to know

hi, I have a problem about sessions, when I start a session, then 
end it, then restart it, session/active? return false if the file 
is not in same location with the file which is started the session.

Which Cheyenne version are you using? Have you tried with the development 
version from SVN repository?

2.7.6.3

on windows/xp home & pro

I did not try the SVN version.

2.7.6.3 is the REBOL version. Cheyenne versions are the ones listed 
here :  http://cheyenne-server.org/download.shtml

So, I guess you're probably using v0.9.19. Could you make small RSP 
scripts that exhibit this issue and send them to me by email?

oh sorry, yes I'm using the 0.9.19, I guess the problem is about 
subfolders

I'm preparing the scripts now..

Thanks.

I remember a similar issue reported once by a user a few months ago. 
I'm not sure this has been fixed properly or if your issue is exactly 
the same. Anyway with the help of your test scripts, I should be 
able to figure it out.

I just send the test files by email

Please try the test cases I wrote in the email, session/active? gives 
2 different result after restarted a session, if the files are different 
folders

Got it, will give it a quick look now.

thanks a lot

Websockets... now we're cookin'
http://mylittlehacks.appspot.com/phpwebsocket

The test cases run OK here with the development version (on SVN), 
which means that the issue has been already fixed. Now trying with 
0.9.19 to be sure.

can I download the SVN version (where?) so I can test it here too

Google Chrome announced support for Websockets recenty. Works well.

SVN version is hosted on google code : http://code.google.com/p/cheyenne-server/

Cheyenne could get some good press by creating a protocol to handles 
ws://

Endo, if you don't have SVN installed, I'll send you a zip archive 
by email?

http://code.google.com/p/phpwebsocket/

I can download it from the web

but there is no binaries I guess, can I run it from the console?

I don't have /Pro versions.

or if you have binaries please send me by email

I'll upload a binary version online, just wait a minute...

Forget that.. download the latest Google Chrome beta and start playing 
with websockets :)

http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

Terry: yes, interesting stuff.

Endo: it's confirmed, version 0.9.19 fails on your test case while 
the development version seems to run it fine.

I downloded 0.9.20, testing in a minute

Let me know if you need other binaries (the one I've sent you is 
made with enface).

Ok, I've tested it, works fine now.

What is the difference enface version?

It doesn't work as a service on my pc. If the other version can work 
as a service, could you please send it to me?

Windows Service mode fixed in SVN r40. Enpro binary available here 
: http://cheyenne-server.org/tmp/cheyenne-r40.exe

Enface = enpro + View engine, more info about various REBOL kernels 
here : http://rebol.com/docs/sdk/kernels.html

Btw, I should use /Face and /Pro terms which are more correct when 
talking about kernel flavours.

Both service & session features works now. Thank you so much.

/face version doesn't work in service mode ... is that correct?  
I haven't tried it again recently.

Right, /Face in service mode can't survive a logoff. It's related 
to how REBOL windows are hooked to screen and lack of correct handling 
of some special events sent by the OS during logoff procedure.

I had a problem to start the recent cheyenne version as a service 
after encapping.
I got always crash.logs that it could not find some files.
After manually copying the files it works.
Can it be that in .cache.efs the new features are not included?

ok, this was not a problem running as a service, but cheyenne.exe 
did not start at all, as it could not find some Uniserve modules.
After adding adding all of them to the cache, it works again.

.cache.efs may have been too old. It is refreshed when you start 
Cheyenne from sources. As a rule of thumb : boot Cheyenne in source 
mode to refresh the encap cache definitions before encapping (especially 
if you did a SVN update).

Thanks,

Cheyenne is really one of the Rebol programs, I use without any own 
modifications.