World: r3wp

I tried to run  Cheyenne as a service.
It installs itself as a service, but does not run.

What OS? Do you have admin rights?

When I test with the scm-100 package, I can open the service manager 
an some pcs, but not on all.
What should I observe, if I want to run Cheyenne as a service?

I used WinXP, Win2000 and Win2003. I have admin rights

I used your latest svn trunk and encapped it with encmd

Testing here on XP, the SVN version doesn't seem to work in service 
mode. You should use latest stable version instead until this get 
fixed.

ok, thanks

encapped with encmd and not encmdface?

doc has said that face prevents rebol apps running as windows services 
.. I didn't know that you could encap without face as cheyenne needs 
that to generate the captcha images ...

I do not need captchas, as I just want to couple some system.

Just curious .. has anyone run phpmyadmin under cheyenne?

I wasn't able to install it even to lamp one time :)

Yes, I had it running a ways back...I did not like the dos window 
that opened up to get php running...

If I want to do REST or SOAP, can I use Cheyenne?
Where do I have to intercept?

Phpmydamin: yes I'm using it sometimes, since PHP support has been 
added. Mostly on Windows. I don't remember seeing the DOS window 
popping up for PHP scripts. Maybe you've used PHP in CGI mode with 
Cheyenne?

no need for an answer anymore, I just looked over some information 
on this

Graham did some work on REST support for Cheyenne. SOAP requires 
a XML encoder/decoder in your RSP script.

Too late :-)

thanks anyway

is there a setting in httpd.comf where I could change how long a 
auth session in webapp lasts?

in the webapp config

timeout time!

thanks

What technique does cheyenne use in regards to spawning of new processes? 
I mean - it either uses 'launch or some form of 'call. I wonder, 
what is the IPC (inter-process communication) strategy. E.g. I have 
10 requests I want to handle simultaneously, I spawn 10 processes. 
How do I pass TCP port to them? Or does it work some different way?

I want to try to plug R3 into Cheyenne to test CGI under Windows. 
I can't understand, how Cheyenne handles CGI though. I can find handlers/CGI, 
where it does some strange stuff. First and foremost - the shebang 
line is ignored, yet CGU it works - you can entirely delete it. I 
can get shebang section evaluated only if I delete REBOL header. 
This is confusing for me ...

Does Cheyenne call somehow internally default installed REBOL interpreter 
on your machine? Or is CGI handled by one of spawned processes by 
the interpreted instance, running the CGI? I simply want it to order 
to use my own interpreter :-) OK, will try with Apache, that will 
be clearer ...

Janko: look in the Cheyenne's ChangeLog file, that's where I document 
new stuff.

Direct link: http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/changelog.txt

Spawning new process: It uses CALL to simulate LAUNCH because LAUNCH 
native wasn't supported by all REBOL kernels IIRC. IPC is done using 
TCP ports : client <=TCP:80=> httpd <=TCP:980x=>worker-process

Thanks Doc

If you want to handle 10 requests at the same time, Cheyenne will 
proxify your requests to background processes (taken from the existing 
preforked pool, additional processes are started if the pool is not 
enough).

Do you use any specific dialect for IPC, or just some basic parsing 
methods? Those questions are just theoretical. Now I am more interested 
into how do I let Cheyenne use R3 for CGI process, instead of R2, 
just to do some testing?

btw.. cheyenne already does by itself what you need frontend nginx 
+ multiple instances of mongrel / cherrypy (TurboGears) / servers 
in the background

CGI handling: two different strategies are applied :


- if the target script is a REBOL script, the process is already 
a REBOL session, so no need to start a new one (and avoid the startup 
cost, so you get FastCGI speed). Shebang line is ignored in that 
case.


- if the target script is not a REBOL script (no REBOL header), classic 
approach is used: setting of environnemental variables, CALLing executable 
from shebang line, sending input, catching output,...

so, my strategy is - use the sheband line, remove REBOL header, right?

To support R3, you have to either hack CGI.r source code to force 
REBOL script to use the general strategy (simple to do, but probably 
poor performances) or implement a mod-R3 extension to setup a custom 
R3 persistent server (more work but faster result).

if you remove REBOL header, will R3 accept to run the script?

hmm, but then I get - ** Syntax Error: Script is missing a REBOL 
header ** Near: do/args script system/script/args

:-)

that is - for R2. I changed REBOL [] to REEBOL in order to get sheband 
line active. The strategy could be simplified, but the 'either code 
would have to be reordered ...

Simply put - if sheband line is there, us it, easy as that. I don't 
understand why normal REBOL header takes precedence ... putting sheband 
line into action is problematic, if you somehow need to use rebol 
script, without REBOL header ...

Hacking CGI.r seems easier. Just patch it to avoid REBOL header detection 
like this: 

script: none		; <= add this line to force classic CGI 
either all [
	string? script
	not empty? script
][

yes ... that is patch for incorrect logic, but easy one :-)

I wanted to make it easier for CGI coders to switch from Cheyenne<=>Apache. 
Using your solution would force users to add/remove the shebang line 
each time you change server (like debugging locally on Cheyenne and 
putting in production on Apache).

Always honoring shebang line would result in poor performance of 
REBOL CGI scripts under Cheyenne.

How is that? Under Apache, I do have to have both - shebang line 
plus REBOL header .... Yes, I understand why the precedence was set 
- because of fast-cgi mode precedence ...

Right, I thought that making REBOL CGI fast under Cheyenne was the 
least expected from a REBOL web server.

Yes, normally yes, because you don't normally care about using different 
interpreter for the task given. It could as well be easily solved 
by some setting/switch - use normal CGI, vs FastCGI ....

for all those years, I used normal CGI on my linux. I found out, 
that even PHP on my server, runs in normal CGI mode :-) But being 
faster is always handy ...

I chosed the simplier and most efficient solution for the user. Having 
to support REBOL scripts using same  header than R2 but with a R2-non-compatible 
kernel was not something planned.

interesting that we've got get-env, but not set-env function in REBOL. 
Either R2 nor R3 do have it ...

btw - it seems that Carl's beta plan might be a bit larger, if he 
is about to accept many additional user requests. There are still 
important things missing, and without them it imo does not make sense 
to call R3 a beta ...

Part of REBOL oddities. REBOL only needs get-env for supporting CGI 
mode.