World: r3wp

noob question .. think i've asked it before .. where should one startup 
uniserve on a linux system?  (suse10) ?

I'm not sure to understand your question Graham. Do you mean how 
to start Uniserve automatically at boot time on Linux ?

yes.

Graham; check out http://www.luv.asn.au/overheads/linux-startup.html
for some hints

Just wondering if Apache can be run as a service from YaST, what 
would it take to run Cheyenne like that?

GO DOC GO! 

(cheerleading helps ;)

Any more thoughts on PHP support?

Is there a Powered by Cheyenne logo?

Doc, please change the error message to "Error Trapped" instead of 
"Catched Error"

(probably Doc is referring to his use of CATCH when handling the 
error.)

Looks like cheyenne went back to sleep :)

Terry: I'm about to release a new version of Cheyenne with a redesigned 
and more reliable RSP engine. I've also started documenting the RSP 
API and features (takes much more time than I expected).

Graham: Thanks for the reminder, I forgot to correct that in the 
previous release. Now it's fixed ;-).

Powered by

 logo: they're is no one currently. I'll enhance the design of the 
 current logo and I'll add a "powered by" logo too (thanks for the 
 suggestion).

Thanks.

Great to hear that progress is still occuring :)

I'm using Cheyenne with RebelBB.cgi at present and it is working 
well.

PHP support: Well, I hope there will be good news soon about PHP 
interface with Cheyenne as soon as I found a way to properly compile 
the latest PHP sources for Windows (compiling under *nix is ok). 
It seems that the latest PHP is able to fork itself automatically 
under heavy load in FastCGI mode. If this feature works well, I'll 
officially include the PHP interface in the next release.

Hi Graham, is your forum online ?

yes ...

but the data is being sent as compressed rebol blocks :)

http://www.compkarori.co.nz:9000/cgi-bin/rebelBB.cgi

ie. it uses a Rebol async client

Are you using a REBOL/Services layer for that ?

no.

Just a rebgui client ..

hadn't thought of using async for the cgi ...

Is Cheyenne's http log standard?
Does it come with any Vid tools for analysis?

Yes it's standard. No analyzing tools, did anyone wrote such tool 
in REBOL ?

VID?  what's that  ;-)

I'd like to something like Webalizer (http://www.mrunix.net/webalizer/) 
done in REBOL.

I'm thinkin' ez-plot/q-plot might be a nice place to start for that 
app.  Hmmm.

I wrote a core based analysis tool some years ago .. dunno where 
it is now!

Great minds think...fire and forget...alike  :)

How would you do the following in Cheyenne?

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+) /cgi-bin/qm.r [QSA,L]


Also, is there an equivalent to -- get-env "REQUEST_URI" -- in Cheyenne?

Can you translate what does it do? My primitive rsp system just needs 
.httaccess modification, setting rebol handler for .html being processed 
by rsp.cgi ...... so all files have to be "in place".

What is advantage of your aproach? (Just asking, as I dunno what 
mod rewrite is good for)

This rewrite rule takes any request (third line) for a file that 
doesn't exist (second line) and redirects to my cgi script.

hah, nice - so, the thing is, that I can have URI, while file does 
not be located at that place? Kind of "virtual file"? :-)

The advantage of this is that my cgi script can make decisions based 
on the full request, not just the query string.

what do you mean by "the full request"?

For example, from this url: http://foo.com/pages/edit/1-- I get 
the Request_Uri value "/pages/edit/1" then parse it -- ["pages" "edit" 
"1"] -- here I have a controller, and action and an id.  It is a 
more enduring approach than http://foo.com/cgi-bin/qm.r?controller=pages&action=edit&id=1

why do you regard it being a difference?

This is veering OT, so I'll point you here:
http://www.w3.org/Provider/Style/URI
http://www.alistapart.com/articles/succeed/
http://www.alistapart.com/articles/urls/

We can discuss further in 'Web'

RE: get-env "REQUEST_URI" : using the CGI or the RSP handler ?

The Rewriting engine for Cheyenne has not been implemented yet. I 
know that Will developed a simple one for Cheyenne/RSP based on PARSE 
rules.

Re: REQUEST_URI, in CGI mode => all request parameters are in  system/options/cgi

Re: REQUEST_URI, in RSP mode => all request parameters are in  request/in 
(deprecated in the upcoming version)

Looking for it in the CGI handler.  Request_URI isn't in the system/options/cgi 
block -- even using Apache, I have to do get-env "REQUEST_URI"

You should be able to obtain an equivalent to REQUEST_URI by join 
several values from system/options/cgi.