World: r3wp

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.

could there be any problem with running two cheyennes on different 
http ports on same computer ?

well, I am quite sure not this is the problem, I thought before that 
the problem was with accepting the port for ex. 8080 but now I put 
nginx in front which will send requests to each othe them depending 
on the virtual host ... but it's the same, one one runs the other 
can't run. Could this be because they use same ports for workers 
or something like that?

not = now

You can't run two Cheyennes on the same PC without some issues.

the logging won't work properly .. I think both will be logged by 
one instead of each having their own logs.

Doc has said he will fix it .. but I doubt it's a priority.

I could live with loging , it's a somewhat temporary solution .. 
but here the second cheyenne crashes

Well, I don't think it serves properly either ...

The workers depend on task-master service which will change it's 
listening port number if run on port <> 80. So no issue with workers. 
But others services have been added like RConsole, MTA and Logger 
which are not "multi-instances safe" yet.

I want to run another webapp on vps where I have site-assistant on. 
but site assistant is written in older version of cheyenne and I 
don't have time to port it to latest right now. that's why I am doing 
this

(and this new app is written in latest) .. maybe I should try to 
port it.. can't take taht much time

Logger service is for debugging messages btw, it doesn't handle HTTP 
logs.

Oh yeah ... it was trace.log I was thinking of.

I don't think I managed to get two Cheyennes working at the same 
time properly.

I used to run several Cheyenne instance on linux server but it was 
a long time ago (v0.9.15 or 16). I didn't do much testing on that 
use case since then.

I am using debian .. I will port s-a to new one .. probably won't 
be that many changes, only problem is testing it all again and being 
sure it works ok ..

and I was so proud how I solved the problem with nginx :)

I'll have a look this weekend on this issue to see if I can get a 
quick fix (it wasn't simple last time I've checked, but the cold 
freezing wind blowing out here these days might help my brain be 
better irrigated ;-)).

IIRC, having multiple instances on Windows was significantly harder 
than on UNIX platforms. I'll run a full testing on that issue tomorrow 
to get a better picture.

you don't have to for my specific case, I am already porting ... 
I would have to sooner or later

It needs to be fixed anyway. I, sometimes, also may have needs to 
run different Cheyenne versions on the same production server at 
the same time. Graham also has needs for this, so I think it's time 
to settle this issue once and for all.