World: r3wp

Thanks ... I'll try that out tomorrow.

Graham: content-disposition should work, but there may be browsers 
or other clients that ignore it. there is a trick that should always 
work though, but i don't know if Cheyenne supports it: use a url 
like this: showfax.rsp/fax000000.tif?otherargs - you probably won't 
need to put the file name after the ? because most servers (and i 
assume Cheyenne, if this is supported) give you access to the actual 
request path.

I can try it .... but I suspect I'll get  a 404

Doc, regarding the issue above, I'm not getting the error now, but 
the content is still corrupted? ie: if I read/binary a .zip file, 
set the header to application/x-zip-compressed, the browser is recognizing 
the file size, but the file itself is corrupted? Happens with all 
binary files.

Do you have an example i can use in the embed-demo.r file that returns 
a binary?

nvm.. the response was sending back a subsequent rebol error.

Content-disposition worked fine! :)

What's the best way to make the params using embed global so I can 
pass them on to subsequent functions?

I don't understand the  "params using embed" part of your question.

yeah..  missing a comma.. 

What I meant was.. I'm using embed, and I want to pass the params 
object to other, non-cheyenne functions that I DO from the /default 
function

Scope issue (my Rebol is rusty)... what I did was copy the content 
->  qstr: make object! decode-cgi to-string req/in/content
and make my own object . Im guessing this is not ideal

I still don't understand where's your issue...What's wrong with :

your-function: func [obj][
	;-- do whatever you want here with 'obj
]

publish-site [
	default: func [req params svc][
		your-function req
	]
	...
]

I've strayed from the path a bit.. I only have one function.. default.. 
then manage everything from there

but I see what you mean...   can the  [req params svc] args be accessed 
outside of the publish-site function?

Terry, that's local arguments passed to callback function. If you 
need to access them from global space, just set a global word to 
arguments value. Did you forgot how to program in REBOL ?

here's my default function.. 

  default: func [req params svc][
    raw-input: trim req/in/target
	if raw-input = ""[raw-input: "index.html"]
	qstr: make object! decode-cgi to-string req/in/content 
	bout: copy ""
	requesttype: "http"
	commander
	bout		 		
  ]
]

I want to pass the params to the commander function

Yeah.. I forgot .

commander params

where's the issue ?

Oops.. I went commander[params]

hilarious

Read http://www.rebol.com/docs/core23/rebolcore.htmlbefore posting 
here again! ;-)

What I need is a PHP lobotomy

PHP is bad, look at what it did to you :-)

I feel so dirty. *sob*

I've wrapped up the latest Cheyenne source code, binary and my web 
to fax gateway in on file

one file .. see http://rebol.wik.is/Hylafax

It's a little rough .. but it works.  Needs some graphical enhancements.

Nice work.

How about making it a Rockstar module?

doc, your website has 0.9.18 but I seem to have 0.9.19 ...

0.9.19 has been officially released yet.

has => hasn't

oops

Graham, that's not a problem.

whew

I've released it as beta and posted the download link here, so main 
Cheyenne's users already have it.

Nenad, if I run Cheyenne, then do something like this... (on a newer 
XP box)

a: 1000
while [a > 0][read http://mydomain.com/a: a - 1]


It blazes along fine.. but gets about half way.. then just stalls.. 
waiting.. then further results will just trickle in.. stall.. a few 
more .. etc

Why?

Memory and CPU are hardly touched?

some security limiter of XP to prevent DoS attacks?

check your system event log

http://www.mydigitallife.info/2005/11/15/windows-xp-sp2-tcp-connection-limit-event-id-4226/

I was thinking it may be the ISP throttling to prevent DoS ?

but it's from the same box.

It's not a concurrency issue, READ is blocking, so just one connection 
at a time. I run the same test here (XP-SP3) several times, no problem. 
AFAIR, the same test was running just fine on SP2.

why would my READ block, and not yours?

Would it be an embed issue?

Cheyenne has an async kernel.

Are you running your test in the same process as Cheyenne ?

no

R2 port behaviour is blocking by default.