World: r3wp

read http://localhostfails

It's interesting... my browser hangs on it... so it's like it's not 
sending the http header to get things going.

I guess try root ...

must be a config problem. checking

tried 8000 too

netstat -an | grep "LISTEN"

( I'm reading from my own installation instructions :) )

needed root after all.

So, I wonder how to sandbox it on this server.

http://69.164.199.93

No known vulnerabilities ...

rotflol.

Anyway, got it running.  It reminds me of another product that comes 
as an exe only.

Maybe I learned something.  Anyway, good to finally run it on a linux 
box.

I just converted the home page to RSP.

dinner time

Doc, do you see any issues with that  on-message function I posted 
above?

If i put a "wait random 10" line within the do-task/on-done function. 
that returns an alert back to the page, then open a couple of browsers.. 
and fire the function in both, I get a lot of strange behaviour.. 
and I'm not convinced they don't block each other?

Carl, it needs to run as root to go below port 1024.

I see you have it running. :-)

Except it would not run for him on port 8000

Carl, it's possible to SU to any user while started as root, but 
that will only work for the processes forked, not the first one (the 
Cheyenne/Uniserve main process). In config file, just uncomment those 
lines, choose the adequate user/group targets and restart the server 
:

	;	user  nobody
	;	group nobody


I need to investiguate more in Apache's sources to see how they achieve 
full SU on all processes.

Terry: on-message function => yes, loading a script on each request 
is ok for debugging, but bad pratice for production. I'm not sure 
that WAIT is safe in Cheyenne callbacks, never tested that, this 
function is not supposed to be used in user code inside Cheyenne 
main process (it would work in a RSP script, but will block valuable 
resources and reduce scalability).

You should try with a timer event instead (if you really need to 
delay it server-side).

Carl, good to hear you trying out Cheyenne 8-)  now you know why 
we need threading in R3 to replace the worker processes.

BTW, I see you are running version 0.9.19 which is a bit old, I really 
suggest you dowload latest SVN from here:
  svn checkout http://cheyenne-server.googlecode.com/svn/trunk/
I personally run it from source. W la Rebolution!

Will: thanks for the info. We can update to it.

Doc: if there's any small thing we can do on our side in 2.7.8 to 
help with SU situation, let me know.  As you know, running the server 
as SU will be a problem for many folks.

Thanks Carl, I'll investiguate that and will send a report of requirements 
to BrianH if necessary.

Doc, have you looked at eventmachine for Ruby?

I have Cheyenne and EventMachine arguing with each other via sockets 
:)

EventMachine: no, looks like yet another event-driven network engine.

It is.

but has threading

Any clues on running R3 for cgi ?

R3 should work as CGI with Cheyenne as long as you provide a correct 
shebang line.

on windows?

On all platforms where Cheyenne can run.

You can test with Perl's examples in %www/perl/.

Doc, this lastest ws:// demo I've been working on is so killer, that 
I'm going to send you $100 to put towards Cheyenne/ websocket development.

All you need is a donation box.... https://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/donate-intro-outside

Didn't know you could do this, but  Ogg Vorbis files can be stiched 
together using read/binary. (There's a hint :)

Terry we are eager to see your new demo 8-)

Terry: waouh, a brand new pair of shoes! Thanks! :-) I'll look at 
how to add that donation button on Cheyenne's web site.

SVN r62


FEAT: RSP scripts can now set response/buffer to a file! value allowing 
main process to transfer it optimally (see changelog.txt)

FEAT: worker tasks now have a more readable and cleaned-up command 
line.

FIX: fixed a bug with internal UniServe's DNS cache querying preventing 
'open-port from working in some cases.

This last fix was blocking sometimes the builtin MTA to connect to 
DNS or MX servers.

<last bug>

Graham,  I've used this code to obtain get/post data in Cheyenne:

REBOL [title: "sitebuilder" file: %sitebuilder.cgi]
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
either system/options/cgi/request-method = "POST" [
    submitted-bin: make string! input
] [
    submitted-bin: system/options/cgi/query-string
]
submitted: decode-cgi submitted-bin

That replaces this Apache CGI code:

#!./rebol276 -cs
REBOL []
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
read-cgi: func [/local data buffer][
    switch system/options/cgi/request-method [
        "POST" [
            data: make string! 1020
            buffer: make string! 16380

            while [positive? read-io system/ports/input buffer 16380][
                append data buffer
                clear buffer
            ]
        ]
        "GET" [data: system/options/cgi/query-string]
    ]
    data
]
submitted: decode-cgi submitted-bin: read-cgi

HTH :)

Nick .. I'm using R3alpha ..and initial testing showed I can't get 
the command line in r3alpha

Donation buttons added to Cheyenne web site at bottom if some of 
you feel inclined to help me spend more time on this project. ;-)

I sent you enough money to buy the right shoe!

Someone else can pay for the left one :)