World: r3wp

This gets it working, but doesn't honour existing files.  mod_qm.r 
(with qm at the top of the list of modules in httpd.cfg):

REBOL []

install-HTTPd-extension [
	name: 'mod-qm

	order: [
		url-to-filename last
	]

	url-to-filename: func [svc req conflo][
		req/in/path: "/"
		req/in/target: form req/in/file: %qm.r
		req/file-info: info? req/in/file
		req/handler: select svc/handlers req/in/ext: '.r
		false
	]
]

Then in the CGI handler, I changed this line (just to see if it works, 
not as a recommendation):

soc/path-info: data/in/url

Finally, in the 'request object in QM, I changed the Request_Uri 
line:

path: any [path-info get-env "REQUEST_URI"]

I recognise this may not be the correct usage of Path_Info, though 
I'm not sure what correct usage is -- the CGI spec explanation doesn't 
really clarify things...

Cheering squad: Give us a "C", give us an "h" ... Go "Chris"  


On a more serious note.  I've offered to help design/beta trial REBOL 
Want Ads.  QuarterMaster seems

like a candidate for this.  There isn't any time pressure, as this 
will take a while, but what is your gut feel for Cheyenne support? 
 From reading !Cheyenne you seem to have got a workable solution 
to get at the REQUEST-URI functionality?  Or was that just me reading 
with rose-coloured glasses?


Just FYI, the very first cut is going to be a blog.r test.  But I 
think rebols would appreciate a little more.

Thanks again by the way.

Sorry people.  This was meant as a private message to Chris...but 
now it's out there and that's...ok.
(Could you hear the Stuart Smalley impression?)

I have a 'workable' solution, but it still has a little way to go.

I'm still not sure how to stop the above code blocking some existing 
filetypes.

Ok, try this:
http://www.ross-gill.com/QM/mod_qm.html

It's mod_static with the 404 response replaced.

I've updated the QM source also to be Cheyenne friendly (still needs 
CGI query/post support):
http://www.ross-gill.com/QM/qm.html

Then the only other change in Cheyenne is to handlers/CGI.r
Replace "soc/path-info: none" "soc/path-info: data/in/url"

Ok, before I dig in.  The mod-qm.r replaces mod-static.r?  Or do 
I just slip mod_qm.r into the mods/
dir?

Slip mod_qm.r into the mods/ dir, then replace 'static with 'qm in 
httpd.cfg

Cool.  Doing...

Note, this expects that qm.r is at your www root.

Yep.

My Cheyenne installation has been modified, but I've noticed crashes 
when adding a trailing slash to an existing file (eg. http://cheyenne/index.html/). 
 I think this happens out the box in mod-static -- when you do info? 
%/path/to/file.r/ and file.r exists, it will return info/type of 
'file but when you read %/path/to/file.r/ you get an error.  Is this 
correct? -- view 1.3.50.3.1 core 2.7.0

Also get the errors with the .exe as well.

Chris, sorry to not have chimed in before, I have a quite modified 
cheyenne that is in production for some time, only I have little 
time to help as I'm evely under pressur, somu guys came up with joomla 
in the company I work for, so it's either me coding from 0 or them 
assempling  jomla modules.. I could clean it up and send u a copy 
but this will be obsoleted by Dockimbel next version. it has rewrite 
rules and a slightly modified mysql protocol and a hihly modified 
mysql wrapper  to support stored procedures and getting data easly. 
like database: mysq://localhost/dbName db-open value: db-get 'table 
'column [{id=?} variable ] .

still our hope is having Dock merging somehow your QM with his cheyenne 
apps concept

should name the whole integration ROCKET !!  REBOL in Rockets 

or ROCK  ... REBOL rocks

;-)

Will, thanks for the offer.  For the moment, I'm trying to keep QM 
server agnostic -- mod-QM is just good enough for Cheyenne support 
(also fixes the above slash problem).  QM needs to mature some, and 
I'd rather that development were contained to one script.  But when 
it is more mature, I can see now that it would benefit from a seperate 
Cheyenne implementation that more efficiently takes advantage of 
Cheyenne's features.

'Rockets' -- I like that :)

There was a question a while back about a REBOL web log analyser. 
 TGD did one.

AnalyseIt!.  Needs a license from TGD though.  It states personal 
use, but kakked when

I tried it under 2.7.6.4.2.  Perhaps they sensed I was days away 
from a trial run.

http://www.tgd-consulting.de/Download.html#AnalyseIt

2.7.6.4.2 = 2.7.5.4.2

nice stuff there btiffin - just wish i could understand it

Mr Weyland has done some beautiful work.  Another reason to advertise 
REBOL as
THEE internationalized scripting language.

Sorry, Weyland is Weyand.  My mistake.

argh, the only longstanding bug I have with cheyenne just appened 
again, the only hint I have is, some client connection seams to stay 
open forever, so after some traffic the system will run out of resources 
and I get things like:

## Error in [task-handler] :Make object! [
code: 500
type: 'access
id: 
'cannot-open
arg1: "/Volumes/data/che/Cheyenne/handlers/RSP.r"
arg2: 
none
arg3: none
near: [do load file]
where: 'do-cache
] !
REBOL Internal 
Error: #415

Program terminated abnormally.
This should never happen.
Contact 
www.REBOL.com with details.

Yikes.  Don't like hearing this.  My site is live.  Only four days 
old now.  Haven't
experienced it - yet.  Don't want to.


Are you running Linux or Windows?  If Linux check out the init.d 
scripts or

http://cr.yp.to/daemontools.htmlfor hints on getting automatic failover.

In the daemontools, check supervise.  If Windows, I'm not up on the 
how-to

anymore, but I think it can be done with services...or some other 
web freebie.

it's running on osx 10.4.9

and this is after x00'000 requests, I can see the list of connection 
"ESTABLISHED" growing with "sudo lsof -l +L -R -V|grep rebol" (suggested 
by Jaime)

Oh...haven't run a Mac since MacOS 7.  :)  Good luck.  If you get 
a solution, please
post.  I'd be curious and appreciative.

OS7 ??

8-)

I think my LC 630 had 7.4 on it.  Maybe 7.5  Long ago...now.

Donated to a dying friend, so when I miss it, I miss him more and 
try not to think about it.

server has 2 ip, apache set up to listen on only on ip, cheyenne 
started after apache will listen to remaing ip. anything here that 
could cause the problem?

eth0 eth1 kinda setup?

main ip +alias

standard osx way to multihost

I dunno anything about OSX, but if it worked for x hundred thousand 
requests, I'd
doubt it.

Before I clog the channel, leave the question open.  The others may 
be able to give

you more direct advise.  Check the Uniserve and Rugby chats as well. 
 Maybe some
hints.

I think a guru is needed here, it may be my modifs (none in uniserve) 
or a cheyenne bug (probaly not, Dock would have fixed it) or something 
in rebol or rebol/osx