World: r3wp

ok, will look for it in an old download.

You can also look at the various mod in the source package (Cheyenne/mods/*). 
Mod-static is probably the most complete (implementing most of the 
callbacks). If you need to process the request in a worker process 
(multitasking), you can have a look in %mod-action.r for an example.

Latest Cheyenne source package is available here : http://www.cheyenne-server.org/dl/cheyenne-r0919.zip

thanks sooo much for keeping with me... I know its a redundant thing 
to do (supporting noobies all over again), but its really appreciated.

It makes a good opportunity to practice my poor english skills. ;-)

ironic, isn't it  ;-)

Is the database name fix in that ?

No, it's in the special release I've made a few weeks before (0.9.20 
beta).

Link was : http://www.cheyenne-server.org/tmp/patch-0920.zip

But I found a few bugs since then, so if you need it now, I can make 
you a snapshot release of the latest stable version.

Max: half-ironic ;-)

Here's the current changelog since 0.9.19 :

v0.9.20 - ??/??/2009


 o RSP: databases definition can now be declared at webapp level allowing 

   multiple instances of a webapp to use the same virtual database name 
   but,
	  pointing to different real databases.
	  

 o Config keyword 'databases now allowed in webapp sections. If defined 
 there,
	  it takes precedence over the global section definition.
	  

 o Systray help message now includes HTTPd port number used by the 
 running
	  instance.
	  

 o RSP: session security improved by binding client's IP address to 
 the session.
	
	o Fixed issue with loading %libc.so for Linux 64bits versions.
	

 o HTTPd: fix a long standing issue with IE5/6/7 extra CRLF sent randomly
	  after POST data.

The last entry was probably the cause of some of the rare "RSP freezing" 
issues. I've stumbled upon it recently while making a demo of one 
of our web-based products using IE7 through a proxy.  By default, 
IE7 switches to HTTP1.0 when connecting to a proxy causing the extra 
CRLF bytes after POST data to appear.

The issues I saw with Cheyenne were all related to IE and POST.

So, v0.9.20 is not released yet ?

Not yet, I'm still working on testing/fixing a few things and will 
add some minor features (like httpd.conf search path for Unix). Anyway, 
it should be out by the end of the month, I don't want to wait longer 
to release it.

All: If possible please hack all information that is useful for others 
as well into the Wiki. IMO that's the best way to build up a "documentation" 
for Cheyenne. And it frees Doc from answering the same stuff again 
and again.

What is this in reference to?

Doc. I have made a testing engine that simulates all sorts of http 
requests for testing my apps in rebol ... it so so works now, so 
I have to improve it still . .. you could also use that to create 
a pack of test suits for cheyenne and each time you make bigger changes 
you just run it and see if things behaved as suspected

Graham, you mean my post? Well, I thin Cheyenne is really nice and 
we should all help to make the docs better. And Doc has setup a Wiki 
for this.

So, who are you addressing?

Is there something discussed here recently that you think should 
be on the wiki?

For example that you can't use SSI from RSP at the moment. Etc. It's 
a general reminder for us all.

Janko, is your testing engine async ?

I'm not sure why you would want to use SSI from RSP .. but feel free 
to document it.

Will, no. It is not like load testing app or something like that 
, it is meant to test functionality of webapp backends -- if they 
do as they are supposed to

I never saw anyone using SSI. This is so oldschool :-)

Graham, read above. And Petr, it ight be old school but this doesn't 
imply it's not useful.

I haven't used SSI for over a decade ... and my recollection is that 
you can do all of that stuff in RSP.

doc, I really need your help.  I've tried quite a few things, and 
cheyenne is starting to behave more like a "chienne" than I would 
like.  ;-)


its funny cause I am trying to prevent cheyenne from doing its magic, 
and in effect, it feels like I'm trying to tell a shaman to stop 
having visions.

I'm almost there, but right now, when I close a connection, it effectively 
terminates cheyenne and all the task handlers    ' 8-o

Une chienne ! ça veut dire quelque chose de particulier en Québécois 
? Parce que pour un français ça fait assez vulgaire ;-)

ca veux dire la meme chose   ;-)

mais ca sonne assez similaire heheheh

Ah ok, j'avais pas saisi la blague :-)

it seems I cornered why cheyenne was dying on port close... yippe... 
but I still have a question.

I'm listening.

hehehe  I hope you didn't my above comment to harshly... its not 
a critique of the tool...  

let me make it clear... cheyenne is GREAT.


its what *I* am trying that is making it react strangely... but I'm 
understanding more and more as I beat it up.

Btw, you can run Cheyenne in verbose mode (-vvv or even -vvvvv), 
it's easier to debug this way. During the boot process, Cheyenne 
will list mods callback matrix allowing you to see/debug the execution 
order for your mod's callbacks.

Max, come one, I didn't yet lost my sense of humour :-)

one = on

first I want to confirm that     flag-stop, returned in most low-level 
funcs    is used to stop cheyenne itself.

yess I have used the verbose, and it has helped me a lot  ;-)

:-) 'flag-stop is a very low-level flag for UniServe allowing to 
quit the 'wait loop. You shouldn't mess with that when working at 
Cheyenne mod level (even at Uniserve's service/protocol level).

ok, that is what was killing uniserve earlier... now I can rest in 
peace with that issue.

second question: maybe not specific to uniserve, but you are probably 
the best suited to answer it, since you've most probably played the 
most with async ports.

IIRC, there's the built-in 'stop-events function available for UniServe's 
services/protocols to allow clean exiting from wait loop.

how can I make sure that I/O writing to an async port is finished, 
before I close it.

my current fix is less than elegant, and most definitely will trip 
a server under load... (wait 1  ;-)

IIRC, when writing on an async port in R2, you're supposed to set 
the 'write mode in port/async-modes. That will make REBOL keep calling 
port/awake function until all the data has been sent.