World: r3wp

ok, I see now.

There's a workaround until I publish the next release (later tonight), 
use : insert databases/remr query

Ok.

databases/remr is pointing to the opened port to the DB server.

Cheyenne has again crashed on me .. leaving one process running.

same error as before ?

No error seen.

the other two processes just died.

can we log this to a local log file ?

you should try with changing the Cheyenne.r encap header to this 
one :

Encap: [no-window quiet secure none title "Cheyenne"]

it will work even if not encapped

but I'm not running encap

oh ?? really?

Ok, try

the 'no-window option will trigger file logging mode

ahh.

it is tested in cheyenne.r startup code and if defined, it will try 
to catch all errors in a local %crash.log file

Hope we aren't giving u too much work!

Not at all Graham, I should thank you for making a big leap forward 
to Cheyenne's stability and reliability. :-)

:)

The session cookie problem is related to incorrect timezone calculation 
in cookies expire time. I'm making a fix for Cheyenne, but due to 
a REBOL bug on Windows (http://www.rebol.net/cgi-bin/upnews.r?view=0005), 
I can't find an easy solution for that platform...

So I guess that I'll add a config option for setting the correct 
timezone for Windows users manually and for /Pro users, I'll support 
the GetTimeZoneInformation() win32 function for automatic setting.

Cheyenne release v0.9.12 beta. Download at http://softinnov.org/tmp/cheyenne-r0912.zip

Changelog :


 o do-sql function improved to support RT's DB drivers. /flat refinement 
 is 
	  supported now too. ODBC insert error fixed too.
	
	o RConsole prompt changed to "Server>"
	
	o CGI's 'path-info now returns the request URL.
	

 o Fixed a bug in RSP session destruction potentially corrupting the 
 internal 
	  session list and giving weird results or behaviour.
	  

 o Fixed a timezone computation bug that was setting incorrect expire 
 times for 

   session cookies, resulting in unstable behaviour. All platforms except 
   Windows.
	  

 o Small patch to parse-request-line func in HTTPd.r to be more 'mod-rewrite 
	  friendly.

Great .. and we can get to test while you sleep :)

global and per domain rewrite rules,  http://reboot.ch/mod-rewrite.r
or http://reboot.ch/mod-rewrite.r.zipalpha quality, whatch out ;-)

Doc!  You da Man!  Thanks muchly.

I'm still not having any luck runing php scripts.  test.php does 
not produce a result...jst a blank page.

never mind...it appears the test script is missing the "php" after 
the <?

doesnt need it

There's some tips I posted earlier in this group

Nenad, proably not necessary to have a method to restart modules 
after modifying... simplly dumped the code into an external file, 
and 'do that instead.

do you 'do them at each request ?

um.. i 'do a script to handle my url-to-filename phase

Im intercepting 404s.. and processing them through a main script 
that handles the DB, generates responses etc.

One problem i just realized is passing  arguments (just started this 
10 mins ago)

I'll probably load the main handler into the module.

or load the functions when I boot cheyenne... this build function, 
reboot server, test thing is annoying

good thing it's not compiled ;)

Im catching the 404s nicely now.. loading up the mootools JS library, 
and pushing dynamic JS back to the page via Ajax.

I'm glad you're having fun with Cheyenne :-)

Actually, using..  do load %myfile  in my url-to-filename phase.. 
it's loading the functions each time, but I'll move them into main 
boot script when they're stable

only a true geek has fun with this stuff.

( I guess that makes me a geek ;)

So, what are your near future plans for cheyenne?

reach v1.0 ;-)

add all the missing features planned for v1.0 (see the cheyenne's 
web page for more info)

I might be able to help with  this.. 
Customizable HTTP error pages.

What did you have in mind?

RE: "How does Cheyenne's performance and security stack up against 
the other indians (Apache, Cherrokee, Hiawatha, ...)?"


Speed: close to Apache2.x for static files (tested a year ago, so 
new tests need to be conducted).


Security: not chroot-ed and no special protection against ddos attacks 
like Hiawatha, no bandwidth throttling (could be added), no CGI time 
limit (could be added), passes Nikto generic security tests flawlessly 
(last time check : few months ago)

Customizable HTTP error pages: server-side redirection on 4xx and 
5xx errors to any pages, user-defined in config file.