World: r3wp

You can change that easily if you're running it from a shortcut icon. 
Edit shortcut properties and set the "working folder" where you like 
it to be.

yeah, but I want that kind of thing to live within the configs... 
 since... its a configuration  ;-)

anyhow.. I can hack it in quite easily... its not that big a deal.. 
just a suggestion  :-)

wrt handler... yes.. I just looked in more detai and the error is 
related to the process-next-job().

I won't make a per log file configuration option, that wouldn't make 
much sense. When I'll had such option, it will redirect all log files 
to the same folder. Still need to finish reading onetom proposition 
to see if there's a better solution.

it should also go to a %log/ folder

meanwhile i wrote a little script to fixup the cgi hash-bang lines 
and give exec flag on them

Doc,    wrt handler.. it really was a stupid error on my part... 
I didn't set the   req/out/code   so I guess it stays in limbo in 
its worker handling, since its not valid for request handling, but 
it has no return error code for reply handling either...

CGI scripts run from Cheyenne don't require the executable flag to 
be set.

Cheyenne extracts the shebang line and CALL it, passing the script 
name as argument.

even on unix?

Yes, all CGI scripts are running on my Linux box, with 644 permissions.

Max: req/out/code is used by HTTPd.r service to know if the request 
is ready or not to be sent back ;-)

yeah, I figured it out by re-reading the rsp and action mods.

So, not only it stays in limbo, but it also blocks other requests 
that might be in the pipe coming through the same HTTP connection.

ah ok.

onetom: even the Perl CGI scripts from %Cheyenne/perl/ are running 
OK without +x flag on my Linux.

(I just need to adapt the shebang line for Linux thought, the one 
in the archive is for Windows)

If I have a single wish, it would be for all of the mods and handler 
scripts to have a verbose rebol header.  it would help a lot understanding 
the hierarchy and purpose of some of the mods.

I agree about the headers: REBOL [ ] is a bit short. :-)

well, the path still should be correct, right?

there are so many layers and un-obvious dependencies ( and little 
details like the error code return on top of it ) in the structure 
of the server that it gets really

onetom: yes the path in the shebang line usually needs to be adapted 
for each local configuration.

Maxim: please throw together a blog entry at least about your rambles, 
so later we can use it to extend the documentation

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

Priorities are fixed per-mod and/or per-callback.

Running Cheyenne with -vvvvv (should be enough) will give you a view 
of the matrix (line by line, per event) when Cheyenne starts.

Dockimbel: I have to thank you for your presentation. Just saw it 
yesterday finally. Now I understand Cheyenne a bit more. Im curious 
about the tricky parts though. Like how do u handle forking and the 
communication between the master and the forks and stuff like that. 
I know it's handled by UniServe

Just hinting what should you write and talk about the next time; 
not asking for explanation now, of course :)

Forking is done when Cheyenne starts, more precisely when the task-master 
service is loaded by UniServe. It starts with a default of 4 workers 
processes. If more than 4 simultaneous RSP or CGI requests are received, 
one or several workers are forked (up to 8). You can change those 
values in %cheyenne.r (search for pool-start and pool-max). It is 
planned to expose those values in the config file for easier access.

Oh, well, you got a quick explanation right now. :-)

Doc yeah... I'm starting to be pretty knowledged on the phases (though 
some things still elude me a bit).


I'm just saying that some mods... like extapp, expire, action, alias, 
internal, etc...  probably have non-negligible effects in the chain 
that some other modules might react to or not (depending).  and its 
currently quite tricky to understand what effects the mods actually 
have on requests and response.


anyhow, as usual, Its not critique its just observation from someone 
"outside the box"   :-)

Communications with the workers are handled by the task-master UniServe 
service. It is done with a TCP channel (Cheyenne/UniServe process 
is the server, workers act as clients). When a worker is launched, 
the first thing it does is to connect to the server and wait for 
a new job. If the TCP connection is lost, the server considers the 
worker dead and forks a new one to replace it. Workers are doing 
their best to maintain this (umbilical) link open, if they encounter 
a fatal error, they severe the link before quitting.

Max: no problem, I have my own critics about the way mod interact, 
the current system is powerful, but can sometimes be hard to follow 
for mod's developers (including me). When I'll work on Cheyenne v2 
(probably coded in Red), I'll redesign that system to make it more 
simple for developers.

aaah, okay, thanks, so that's why there are so many tcp ports... 
i thought those r just for debugging the workers during operation

(which also lack an example, i guess. but let's focus on this logfile 
issue now :)

Several ports: Cheyenne is using several other listening ports for 
additional internal services:
- task-master: 9799 (worker process management)
- RConsole: 9801 (local debug remote console)
- logger service: 9802 (centralize all worker logs writings)
- MTA: 9803 (Cheyenne's own Mail Transfer Agent)

That's why, when started multiple times or when one of these default 
listen port is already taken, Cheyenne translates the service(s) 
on other free ports.

oh, that's important to know, because my plan to have the users run 
their own cheyennes might have problems

Max:"its currently quite tricky to understand what effects the mods 
actually have on requests and response"


Agreed, some mods, like mod-static or mod-action are catching a lot 
of events and doing important things. The only way to not get lost 
is to treat it horizontally (from the slide), it means see list all 
mods catching a given event, see the process order and the exiting 
condition: 
- none: not processed

- false: processed but let other lower priority mods callback catch 
it too

- true: processed and stopping the event propagation to lower priority 
mods callback

btw, these lots of ports might look scary for the usual paranoid 
sysadmin, so it's not a good selling point. by default these all 
should be closed, but only port 80 or 8080 or something like that 
should be open

Dockimbel: you r actually writing an awesome documentation rightnow. 
if i can get access to the wiki, i would quote these on a sandbox 
page, so later we can massage it into an actual documentation

onetom: it should work OK with the "port translation" system, it 
is just consuming more listening ports.

onetom: those ports I listed are for Cheyenne internal usage, they 
should never be reachable from outside on a properly configured server 
(requires a firewall as REBOL binds ports to all interfaces). You 
should just let the HTTPd ports be reachable from outside.

onetom: if you need a wiki account, let me know.

I've been using Cheyenne for personal web server for a few years 
now ... only issue was when user installed it as a service

usual paranoid sysadmin

: If I was a fulltime sysadmin, I would be much more scared to put 
any PHP app online than to run a webserver written in an obscure 
language. ;-)

No virus has yet found how to use Cheyenne's mta :)

Good to know :-)

Could be a nice selling point.