World: r3wp

the stranger situation was with Mozilla - 16 test, only 4 or 5 boxes 
were filled, then I got busy indicator ....

I will have to check on my antivirus etc.

Tested on a linux box with Firefox : no error.

rebooted, trying 4 example, it loads 3 sessions imediatelly, stops 
not displaying anything for fourth box, just got a busy indicator 
...

Win2K ....

Try with the source version, not the encapped one.

still the same ... the interesting thing is the difference between 
the IE and SeaMonkey - Seamonkey returns 3 IDs, IE returns all errors, 
but somehow it "unblocks" the "channel" for SeaMonkey, which finishes 
afterwards. Then reloading page in SeaMonkey works ...

hopefully there is no problem with using localhost. In Seamonkey, 
using http://localhost, I get three results, then it blocks ... with 
using http://my-ip-addressI get 3 errors (311), then it blocks too 
...

I will upgrade Seamoneky to the latest one ...

error is in protected-exec Near [print session/hits txt 244 268] 
- Invalid path value: hits ... like it would not know that session 
object variable ...

print = prin

Session are maintained by cookies, maybe you've disabled cookie support 
in your browser ?

no way ...

I can see cheyenne cookie in the list of cookies for SeaMonkey ...

I'll set up an online bug database soon.

Does anyone know if RAMBO source code is available ?

AFAIK it's not available

Maybe I should post a news on slashdot stating that the RAMBO is 
released and point to REBOL.com website ? ;-)) Looks like this method 
works quite well ;-)

hmm, then we should post about Rebol 3.0 alpha too :-)

[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...

## Error in [uniserve] : Cannot open server task-master on port 9799 
!
[uniserve] Starting HTTPd...
## Error in [uniserve] : Cannot open server HTTPd on port 80 !

is all I get...

Is there supposed to be a file called show.r? I can't find it.

don't you run another httpd task (e.g. apache) on port 80?

pekr, I found a Uniserve task buried in the background :-)

Ok, show.r is show.cgi.  But it doesn' t work for me.

Doc, I asked Carl for the Rambo source once and he gave it, so perhaps 
if you ask him (or even better: to publish it...)

Thanks Marteen, I'm using currently Mantis for bug tracking, so maybe 
I'll stick with it...Anyway I'll ping Carl about RAMBO.

very great work!!! many thanks for it ;-)

doc, why not just use trac ?

Doc: maybe if you ask Carl he'll send you the code for RAMBO. I know 
he's very open to this.

ah, Maarten said the same :)

Mantis is far more advanced bugtracking tool than Trac.

ok

Probably a stupid question, anyway, how to change the port to something 
else when running the cheyenne.exe ?

I think if you want to change the port...you have to use 'cheyenne.r' 
instead.

just change the port-id in HTTPd.r and double-click 'cheyenne.r'

there's a -p command line option to set the listening port (80 by 
default). Example: cheyenne -p 8000

I see you plan on supporting SSL... is this in any way functional? 
or should we simply do a reverse-proxy through apache for now?

(even if it depends on pro/sdk license, btw ?)

Strange quesiton...does Cheyenne do PHP?  Don't ask!  Also, which 
version of core/view is required.

It could probably call php as a cgi, but I don't think it's designed 
for such a purpose. And about version - the latest available are 
probably the best.

I would not use view for server

I'm not sure, if you can run it from Rebol/Base, you may try it.

Maxim: I plan to support SSL natively in REBOL. I'm waiting for Carl 
to send me a test version of /Command with server-side SSL enabled. 
In the meantime, I recommand using a SSL proxy rather that Apache. 
See STunnel for example.

The SSL support will be available only in Cheyenne binary releases. 
You'll need a /Command or /SDK license to make it work with the sources.

Scot: Cheyenne can interface with PHP using FactCGI. A FastCGI client 
alpha implementation is currently built in Cheyenne. All you need 
is a php executable compiled with FastCGI. I've already tested several 
php apps (even big ones like eGroupware), it works well and it's 
fast ! But, the configuration options are currently hardcoded in 
Cheyenne (need to export them in config file) and there's no dynamic 
php instance management (you have to launch each php-fastcgi server 
by hand). Once these 2 feature will be integrated in Cheyenne, you'll 
be able to run easily and php application.

Scot: REBOL/Core 2.6x or View 1.3.x are ok for Cheyenne. Avoid the 
experimental async REBOL kernels.

is FastCGI.r usable separately as a free fastcgi protocol for REBOL, 
or does it work only in terms of Cheyenne?

Oldes: View can be a good choice for server is you need server-side 
dynamic image generation or manipulation. The drawback is for Unix 
servers, they'll require X libs to be installed.

Pekr: The protocol is not specific to Cheyenne, but you'll have to 
"extract" it from the module to be able to reuse it. But, we're talking 
about a FastCGI CLIENT implementation, and what you have in mind, 
I guess, is a SERVER implementation (like in /Command)...

so how does it work then?

run easily and php application
 = run easily any php application"