World: r3wp

for your local environment.

SSI:Any examples available?

And, is it possible to "call" a RSP file?

call = include

You can include RSP files .. useful for dynamic headers and footers.

And bodies ;-)

Didn't want to make it confusing for you.

SSI: http://en.wikipedia.org/wiki/Server_Side_Includes

Doc, I'm trying Cheyenne (the encapped version) on a Linux server 
with moderate success. Can I use an httpd.cfg that is not stored 
in the same dir as the Cheyenne executable?

How much of that do you support?

Cheyenne's mod-ssi currently only supports FILE and VIRTUAL directives 
(that's probably 90% of SSI usage). I've planned to add all the other 
missing directives, but it's quite low priority.

Httpd.cfg : no, it has to be in the same folder.

OK, thanks.

Ah wait, maybe not, I need to check the code.

It would be nice to store the exe where it should be and the config 
in /etc.

That's specific to Unix system.

But I already have some specific data folder handling for Windows...so 
why not.

There's a -f %folder/ option for command-line, but it seems to be 
honored only for Windows platforms.

henrik, won't that be a problem if you run more than one chyenne 
instance?

Btw, I always found very user-unfriendly  the Unix approach of dispatching 
application related files through the whole filesystem...Pity that 
the GoboLinux philosophy didn't spread over all the others distros.

Graham, I'm not sure. Would I want to run more than one? I'm not 
counting the processes that Cheyenne manages.

will there still be an option to have it in the same folder if you 
change this? maybe as command line arg

Henrik, you may not want more than one instance running ... but someone 
else might.  so, I think it needs to be as flexible as it can be.

Agree.

Doc, agree too. It's a mess. And a time-killer if you start using 
Linux. Where can I find ABC etc.

I think to add on Unix, search paths for config file in the following 
order : local folder, $HOME, /etc/ . Would that be enough to cover 
all use cases?

fine by me

I just tried to run cheyenne as a service on my WinXP Pro, it generates 
crash log and says "cannot-open service.dll"

I used a file monitor and found the reason, it tries to load mcvcrt7.dll 
(visual c 7 runtime dll)  can't find it and gives error with "can't 
open service.dll"

my os is xp pro sp3 so I suprised why mcvcrt7.dll is not there. anyway, 
if somone has the same problem just copy the dll to your system32 
folder.

Endo, thanks for your report. I'll check if mcvcrt7.dll is part of 
standard Windows installation. If not, I may switch to a statically 
compiled DLL.

From Linux channel .. I will first have to make my webapp compatible 
with the latest version on local computer

doc, what is the easiest  way to trap connections and take decisions 
based on the current context of the server?

this is a real use case, not just a question in the air... I have 
to help a client with a problem they have.  not a cheyenne bug, but 
the way its being used by their clients.

I'm not sure what you mean precisely by "to trap connections" and 
also "current context of the server"? Are you talking about hacking 
  the HTTP layer in Cheyenne?

I need to be able to verify a connection from a client right when 
it happens.  so that I can refuse it based on some conditions and 
do some other client-internal stuff.

Like IP address?

no, based on the current state of connections on the server.  quantity 
of connections for example.

http is stateles .. so what are you going to measure?

Max, that would require writing a specific module for Cheyenne. Connections 
number can be measured by doing a : length? system/ports/wait-list 
(and subtracting worker processes local connections).

how many connections are actively being served , time since they 
connected (to enable better timeout handling), etc.

Cheyenne network I/O layer (UniServe) tracks connections timestamps 
and manage timeouts automatically.

ok and is there a document which explains easily how to create and 
link a module at that level?

and if users just let their connections timeout instead of logging 
out ....

You can find a short doc for Cheyenne's mods API in %Cheyenne/docs/developer-guide.html.

If you want to manage connections by yourself, you need to dive deep 
into UniServe's engine to avoid conflicts with its own connections 
management rules.

ok, is there anything documented on that side? or is it (what I expect) 
seek & destroy into the code itself?

There's a UniServe user documentation, but UniServe internals are 
not documented.

ok. thanks, you`ve already helped me save some time  :-)

Maybe there's a more simple solution for what you want to achieve 
than hacking UniServe? I still don't get exactly what's your goal. 
Is it debugging? Is it adding a new feature to Cheyenne?