AltME groups: search

Moving up, you could write a FastCGI server that would solve that 
problem and would also be more performant

I think the FastCGI server is doable now. Instead of writing a complete 
one, you could probably also find a library written in C and bind 
to it

There's something deep-down that is wider than View.

Run enough CGIs under Core and you'll get what seems to be the same 
sort of error.

Which is weird as each CGI is a separate incarnation (when not using 
fastCGI, anyway).

Yeah, looking at his site, it seems that he patches rebol.exe so 
that it loads an additional dll that does the work. He has another 
for FastCGI.

Imo we should aim for REAL kernel - where all unnecessary things 
should be removed - I talk about fastcgi, db drivers etc.

Ok, but who will develop those modules? Would they be open source? 
Personally, the reason why I love rebol is because it allows me to 
focus on the business, not on the tehnical aspect of a database, 
fastcgi, etc... I am certainly not the one who will develop technical 
modules, simply by lack of knowledge and time. But I really need 
those db access, fastcgi, etc...

is there anybody trying to use fastcgi scripts with encaped scripts 
?

is that rebol fastcgi ?

Hi, I have some trouble to configure apache to use fastcgi with Rebol/Cmd.

I am using apache 2 with module fastcgi

Hello, I finally get FastCGI with rebol/cmd with Lite Speed Web Server, 
but not with Apache.

Anyway, it works, but I still have a problem: in system/options/cgi, 
both 'path-info and 'path-translated are set to none, which prevents 
Magic! to wrks properly as it can not find the requested file (usually 
a *.rhtml) file. In normal CGI, it works well. Is this a bug? In 
that case, I will put it into rambo. Note that I have configure FastCGI 
in compatibility mode.

It looks like the problem does not come from the past-translated, 
but from the 'request-method: with CGI, the values are "GET" or "POST", 
but with FastCGI, the values are "GET^@^@^@^@" or "POST^@^@^@". But 
with lighttpd, no problem. So to make FastCGI rebol scripts work 
with LiteSpeed, we have to update the exemple http://www.rebol.com/docs/words/wread-io.html
as:

LiteSpeed and lighttpd are both amazingly easy to install and configure 
and works fine with Rebol/Cmd in FastCGI (both in compatibility and 
external modes). Furthermore, those web servers are much faster and 
reponsive than Apache 2.0 (2 to 6 times faster!!)

With LiteServer and lighttpd (normal CCI and FastCGI) i have: 
make object! [
	...
	path-info: "" 
	path-translated: none 
	script-name: "/sample01.rhtml"
	...
]

Can anyone help me to configure apache 2.0.x and rebol for FastCGI 
under Windows XP?

You should note, that Rebol fastCGI is incomplete (=crippled!), and 
so you can run FastCGI in External mode only, and I regard it being 
a BIG limitation. Pity DocKimbel did not release his FastCGI for 
Uniserve yet ....

Hi, for those interested, a modified and slightly improved version 
of Magic! for FastCGI is available on www.rebolgique.net....

The Rebol Directory Project (www.rebolgique.net/rdir/) is an exemple 
of application developped with FastCGI and Rebol/Command. This application 
is in its early stage, but is intended to become a database with 
as much inforamtion as possible about the members of the rebol community...

Can anybody give me an exampkle setup + explanation of FastCGI + 
lighttpd with FastCGI; also on the Rebol side. I know Francois mentioned 
it was easy but I don't get how you can do adaptive spawning one 
the same listening port (e.g, 10 Rebol FastCGI processes listening 
on port 1026 or so)

I used fastcgi in the past, wich Apache, under linux. All modes worked 
fine IIRC. However, under windows, the implementation was crippled, 
and only external mode worked.

Also, there was problem, that the same client could be served by 
different process, so fastcgi guys implemented some kind of "afinity 
patch", kind of proxy, which then connected the same client always 
to the same process.

Hope you read http://www.rebol.com/docs/fastcgi.html

I am close to autogenerating fastcgi processes, linked with Lighttpd 
configs and generating automagical includes that match the web server 
config  for encap/Pro.

I am also adding a routing scheme (dialect) so basically you redirect 
all traffic except static stuff to a fastcgi process, it comes in 
the router and then it checks on extension or path (REST) what to 
do.

Maarten, this sounds very cool. So the goal is to have a scalable 
web-service framwork based on fastCGI and simple tools?

But  yes: load-balancer -> webserver(*) -> FastCGI(*) -> MySQL

FastCGI is a rebol process with core enhancements, session mgt, RSP 
etc. I am also integrating autodoc from Gabriele so the files will 
be more "literate" and I have a module management system in place 
thathandles from interactive to encap.

I don't understand it a bit. I can understand webserver, fastcgi, 
mysql part, but what is that load-balancer part? Client side?

No, before the webserver, so you scale transparantly to multiple 
webservers (in my scenario each webserver effectively is the load 
balancer for X FastCGI rebol processes; it's how nginx and lighty 
work)

Did you do any speed comparisons to classical templating engines? 
:-) I read about smarty, its compilation etc., but found it unpractical. 
Maybe Temple with FastCGI could be even faster, as it could have 
some templates preloaded :-)

I would think FastCGI should provide good enough performance. 


Reichart's team is gunning for 0.30s processing for their scripts 
in QTask. That seems a reasonable limit.

Hello, there is also FastMagic!, a refactoring of Magic! to work 
in FastCGI mode... It also add some usefeull tags like <rebol:include> 
<rebol:if>, <rebol:forall> and <rebol:make-doc-pro>. Rebol Directory 
is being developped with it and the code is available at d2740.servadmin.com/~francois/. 
You will find both fastmagic! code and the code of Rebol Directory 
as well...

And you can switch from FastCGI to CGI but modifying the flag mod-fastcgi 
in the file fmagic.r

Magic! is CGI
FastMagic! is FastCGI

François, thanks, I was already wondering how hard it would be to 
scale up Magic! with FastCGI. Do you have any idea how many users 
FastMagic! could serve?

Francois - that is not true - you can hold just one db connection 
;-) FastCGI is nothing but advantage :-) you simply can use code 
like following to check if you have already opened connection ... 
exists-conn?: false .... if not exists-conn? [open-your-db-connection-here 
exists-conn?: true]

quick question on Magic and FastMagic.

I understand that FastMagic supports FastCGI.


Is there any difference between the requirements? Does FastMagic 
requires /cmd  or just /core?

where can I find more info. on FastMagic

Only /Command has FastCGI built in. AKAIK, there is no complete implementation 
of FastCGI for /Core. When last I heard, development of one was stopped 
voluntarily to avoid devaluing /Command.

Given that, a REBOL language version of FastCGI would probably have 
to work differently, and FastMagic would then need a little recoding 
to work with it.

Kaj, FastMagic! does not require SQL database. But it does require 
Rebol/Command and Linux. Indeed, FastCGI in CGI compatibility mode 
needs a POSIX environment. Nevertheless, you can use FastMagic! in 
normal CGI mode, by setting the flag mod-fastcgi to false (in the 
fmagic.r file). Actually, i develop under windows in CGI mode and 
deply under Linux in FastCGI mode, and it workds well. I tried to 
be as much compatible as possible with the original Magic!. Again, 
the application code for Rebol Directory is definitly the best way 
to learn how to develop with (Fast)Magic! You can download it at 
www.rebolgique.org

There is a free FastCGI for Core --> check agoradev.org . it also 
was tested with magic! the author was cocinelle

the fastCGI was nicely coded and was public domain license

or I will miss fastcgi ....

On Windows, /Pro supports fastcgi - what about on Linux?

(I think Pro suffices anyway though. It has encryption and FastCGI 
on board)

Mike, I started using Apache and rebol as cgi, this is not suited 
for performances as on every call to the cgi, a new instance of rebol 
is  initialized, run and closed.

I thought about using fastcgi, but never came to a working solution.
Now I use uniserve as main webserver, here some advantages:

-it is fast! On my local machine I get +- 600 req/sec for static 
pages and a max of 160req/sec for dynamic rsp pages

-it is written in rebol, I could easly(less than 10 lines code) add 
a rewrite engine

-child process are persistent, this mean you can keep state of your 
web applications, implement caching, keep a pool of connection to 
databases open (in apache + rebol/cgi you'd have to open and close 
the connection for every request)
-it is written by Dock whom I may be the biggest fan ;-)

btw I'm running an unreleased version (have bought commercial support) 
 that support http 1.1, stuff like If-Modified etc..

If you have more specific questions, I'll be glad to try and answer.

Need some help...Can't seem to get Uniserv working on my XP laptop. 
 This is my first try...so I don't have enough experience to see 
what is happening.  Do I have the wrong version of core?

>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new
>>

I figured out how to stop the service tying up the 80 port , When 
i run this is what I get: >> do %/c/temp/rebol/uniserve/uni-engine.r
== true
>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new

just ask DocKimbel to release his xy years old version. He did not 
do that, because RT asked him not to do so. IMO fastcgi is not feature 
which would ruin RT sales. Except secure mode there is very little 
value in the rest of Command - outdated ...

The power in Rebol is different. I think Rebol is good for KISS, 
where simple things are simple, hard things are hard. Like adding 
co-routines. We added this feature to BEER. It works but they require 
careful programming of your routines. Otherwise you get blocking. 
The solutions is R3 tasks. Similarly situation has happend with other 
features, like the FastCGI request that I see sometimes, or callbacks 
for C routines which was dormant inside the interpreter for years 
until discover by cyphre and later released.

[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...

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.

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

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)...

It supposed to work almost the same as mod_fastcgi for Apache.

It connect to a server application, like php-fastcgi or a REBOL FastCGI 
server built with /Command, or any other server accepting FastCGI 
clients. Then it sends the HTTP request and wait for a response back.

The trouble is with Windows, we still have no-solution. Command Windows 
fastcgi was never fixed - 'external mode is pretty useless

ok, the trick is to use Cheyenne plus Rebol instead of apache, so 
who needs fastcgi :-)

Will "Mike, I started using Apache and rebol as cgi, this is not 
suited for performances as on every call to the cgi, a new instance 
of rebol is  initialized, run and closed.

I thought about using fastcgi, but never came to a working solution.
Now I use uniserve as main webserver, here some advantages:

-it is fast! On my local machine I get +- 600 req/sec for static 
pages and a max of 160req/sec for dynamic rsp pages

-it is written in rebol, I could easly(less than 10 lines code) add 
a rewrite engine

-child process are persistent, this mean you can keep state of your 
web applications, implement caching, keep a pool of connection to 
databases open (in apache + rebol/cgi you'd have to open and close 
the connection for every request)
-it is written by Dock whom I may be the biggest fan ;-)

btw I'm running an unreleased version (have bought commercial support) 
 that support http 1.1, stuff like If-Modified etc..

If you have more specific questions, I'll be glad to try and answer."

No, it's a client implementation of my own (/Command implements a 
server-side FastCGI protocol)

Terry: Any php script would work, you just have to connect a php 
exe compiled with fastcgi support. I'll give more info on how to 
setup such config once the fastcgi module will go beta. I plan to 
bundle a php exe with the binary Cheyenne with no setup needs for 
end user.

Both versions act the same. Win XP Home. No crash.log file found. 
 This is what loads:

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

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.

heh, I have got crash with latest version:

[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...
make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'add
    arg2: 'time!
    arg3: none
    near: [time: time + port/timeout
        if
    ]
    where: 'close-expired
]


I run Apache on port 80, so I changed httpd to 8080 ... sinmple CGI 
works, I logged into application OK, simple page worked, 4 RSP test 
crashed with above error ...

About PHP support, it works ok and out of the box with latest PHP 
binary on non-windows platforms. We tested it with phpMyAdmin and 
WordPress. It still not ready for production,  due to scalability 
issues. I need to improve and finalize my FastCGI protocol implementation 
to fix that.

Looking at the latest PHP windows binary 5.2.2, it seems that finally, 
they properly included the FastCGI support !! That's great news.

if the fastCGI mod in Chayenne is working you should add some comments 
here http://en.wikipedia.org/wiki/Fastcgi

Doc, at the moment the best approach is to use RebServices via CGI 
(so that it can be used from behind firewalls & proxies). But CGI 
spawns a new process each time and RebServices isn't FastCGI aware 
at the moment.


Hence my idea, if we can tweak a bit and keep RebService running 
on the server but still use the CGI interface to access it. As Cheyenne 
is all Rebol code I thought it should be simple to integrate RebService 
either into Cheyenne or include a nice interface.

robert, did you try services with fastcgi in cgi emulation mode? 
any problems with it?

Has anyone tested php on windows. And do I need to uncomment : ;	bind 
fastcgi to [.php .php3 .php4] and :;	extern fastcgi [
;		command	 "php -b $port"
;		pool 	 min 1 max 4
;		server	 192.168.0.100 ; port 1234
;		root-dir "/home/dk/fcgi/"
;	]

command will detect tha apache called it as fastcgi and will stay 
running

Ok.. PHP is running on XP.. 
uncomment this line in httpd.cfg

bind fastcgi to [.php .php3 .php4]

That way Cheyenne achieve FastCGI speed on normal CGI scripts.

It's not a short paste...
[HTTPd] ================== NEW REQUEST ==================

                                                         [HTTPd] Request Line=>GET /testapp/ HTTP/1.1

                                                                                                     [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 302 Moved Temporarily
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/login.rsp


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Connection closed

[HTTPd] ================== NEW REQUEST ==================        
                                        /

                                                         [HTTPd] Request Line=>GET /testapp/login.rsp HTTP/1.1

                                                                                                              [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )
[HTTPd] Response=>
                  HTTP/1.1 200 OK
Server: Cheyenne/0.9.11
Content-Length: 482
Content-Type: text/html
Connection: Keep-Alive

Set-Cookie: RSPSID=EISPOMAZTPDFKVIWJAFONZDE; expires=Sat, 02 Jun 
2007 11:54:30 GMT; path=/testapp; HttpOnly
Pragma: no-cache
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Dec 1994 16:00:00 GMT


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

[HTTPd] ================== NEW REQUEST ==================        
                                                       \

                                                         [HTTPd] Request Line=>POST /testapp/login.rsp HTTP/1.1

                                                                                                               [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp
Content-Type: application/x-www-form-urlencoded
Content-Length: 23


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Posted data=>login=test&pass=letmein

                                                                                                [HTTPd] Phase access-check done ( mod-action )
 [HTTPd] Phase set-mime-type done ( mod-action )

                                                [HTTPd] Phase make-response done ( mod-rsp )
[HTTPd] Response=>
                  HTTP/1.1 301 Moved Permanently
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/

Set-Cookie: RSPSID=YDADUIONKJPHLFBWEDZDFCXN; expires=Sat, 02 Jun 
2007 11:54:37 GMT; path=/testapp; HttpOnly


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

                                                                                                                        [HTTPd] Connection closed
    [HTTPd] ================== NEW REQUEST ==================

                                                             [HTTPd] Request Line=>GET /testapp/ HTTP/1.1

                                                                                                         [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 302 Moved Temporarily
Server: Cheyenne/0.9.11
Connection: close
Location: /testapp/login.rsp


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Connection closed

                                                                                                         [HTTPd] ================== NEW REQUEST ==================

                     [HTTPd] Request Line=>GET /testapp/login.rsp HTTP/1.1

                                                                          [HTTPd] Request Headers=>
Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 
Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/testapp/login.rsp


[HTTPd] Phase url-to-filename done ( mod-alias )

                                                [HTTPd] Phase url-to-filename done ( mod-rsp )

                                                                                              [HTTPd] Phase url-to-filename done ( mod-fastcgi )
   [HTTPd] Phase url-to-filename done ( mod-static )

                                                    [HTTPd] Phase access-check done ( mod-action )

                                                                                                  [HTTPd] Phase set-mime-type done ( mod-action )
    [HTTPd] Phase make-response done ( mod-rsp )

                                                [HTTPd] Response=>

                                                                  HTTP/1.1 200 OK
Server: Cheyenne/0.9.11
Content-Length: 482
Content-Type: text/html
Connection: Keep-Alive

Set-Cookie: RSPSID=RTJSUKAVYBNOLCJCJBSTNUHP; expires=Sat, 02 Jun 
2007 11:54:37 GMT; path=/testapp; HttpOnly
Pragma: no-cache
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Dec 1994 16:00:00 GMT


[HTTPd] Phase logging done ( mod-static )

                                         [HTTPd] Phase clean-up done ( mod-rsp )

                                                                                [HTTPd] Phase task-done done ( mod-rsp )

hmm.. followed the instructions.. uncommented the httpd.conf (need 
to comment out the others??)

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

## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'in
    arg2: 'object
    arg3: [object! port!]
    near: [if in site 'on-request [
            if site/on-request req params svc [return true]
        ]]
    where: 'handler
] !

Script: "Cheyenne Web Server" (9-Jun-2007)
Script: "Untitled" (none)
[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...
make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'do-events
    arg2: none
    arg3: none
    near: [do-events]
    where: none
]
>>

>> do-events: func [
[        "Process all View events."
[    ][
[        wait []
[    ]
>> do %cheyenne.r
Script: "Cheyenne Web Server" (9-Jun-2007)
Script: "Untitled" (none)
[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...

Re: php / fastcgi, didn't had time to work on it this week, but it's 
high priority for my company, we need to put a few php apps onlin 
with Cheyenne, so I'll work on that in the next days.

>> test-string: "11 22 33"
== "11 22 33"
>> dehex test-string
== "11 22 33"
>> do %cheyenne.r
Script: "Cheyenne Web Server" (9-Jun-2007)
Script: "Untitled" (none)
[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting HTTPd...
(escape)
>> dehex test-string
== "11 22 33"

Cheyenne release v0.9.15 beta. Download at http://softinnov.org/tmp/cheyenne-r0915.zip

Changelog :

v0.9.15 - 20/06/2007


 o RConsole was not started by default in the previous release. Fixed
	

 o RSP: 'include function protection from infinite cycles changed. 
 It's

   now based on a counter (5 maximum recursive includes). It's a little 
   less

   cleaner than stack-based tracking but much more reliable (avoids 
   matching
	  paths and targets).
	  

 o HTML.r library rewritten from scratch. Now, faster and more conforming 
 to 

   standards (Full range of Latin1 entities supported). Fixes URL-encode 
   bugs.

	o BugFix for command line parsing in encapped Cheyenne on Linux.
	

 o Fixed an issue with 'decode-multipart in RSP.r. File upload should 
 work ok 
	  again.
	  

 o Added a new global function : 'rsp-log value. Outputs values in 
 console for 
	  debugging RSP scripts. Works as 'probe.
	  

 o Reloading config file now supported. Running sessions and client 
 connections

   survive to the reloading process (needs some additional testing). 
   Activating
	  config file reload is done using:
	  
	  		- (Windows) "Reload Config" menu option in systray icon.
	  		- (UNIX)     kill -s HUP pid
	  		

 o UNIX signals SIGINT,SIGQUIT,SIGTERM now catched to allow cleaner 
 exit and last

   minute actions. Triggers the new 'on-quit event for HTTPd modules.
	

 o HTTPd internal events (not phases) refactored to be cleaner. New 
 module's
	  events added:
	
			- 'on-started:	when Cheyenne starts.
			- 'on-reload:   before a config file reload happens.
			- 'on-reloaded: after a config file reload happens.
			- 'on-quit:     when Cheyenne is about to stop and quit.
			

 o RSP sessions can now be made persistent (can survive to a server 
 complete restart).

   This option is controlled by a new config keyword: 'persist. Usage 
   is :
	  	
	        persist [sessions]    ; other flags can be added at will
	        

 o BugFix in session cookie handling for web-apps using 'auth mode. 
 Now the cookie

   is sent on the 302 redirection to the login page avoiding the creation 
   of a 
	  "shadow session" that will never be used. 
	  

 o FastCGI is under heavy work so mod-fastcgi is commented in config 
 file to avoid

   fastcgi startup. If you want to play with PHP, just uncomment the 
   line.

trying to run php ... how should I configure my fastcgi section properly?

	extern fastcgi [
		command	 "php -b $port"
		pool 	 min 1 max 4
;		server	 192.168.0.100 ; port 1234
;		root-dir "/home/dk/fcgi/"
	]
] 

what is server ip and rootdir here?

Because, the interfacing with PHP is still under development and 
lacks full path resolution in mod-fastcgi. Remember, that the PHP 
support is not a production-level feature, it's in alpha stage !

did you uncomment the 'fastcgi lines in httpd.cfg ?

;	fastcgi

bind fastcgi to [.php .php3 .php4]

modules [
;	userdir
	internal
	static
	action
	fastcgi
	rsp
	ssi
	alias
;	embed
]

globals [
	bind SSI to [.shtml .shtm]
	bind fastcgi to [.php .php3 .php4]
	
	bind-extern CGI to [.cgi .r]
	bind-extern RSP to [.j .rsp]
	
;	user  nobody
;	group nobody

]

default [
	root-dir  %/c/!Docs-private/Xidys/cheyenne-r0914/Cheyenne/www/
	
	default [%index.html %index.rsp %index.php]
	
	on-status-code [
		404	  "/custom404.html"
	]
	
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp"
		debug
	]
	
;	"/" [
;		redirect http://softinnov.org
;	]
	
;	extern fastcgi [
;		command	 "php -b $port"
;		pool 	 min 1 max 4
;		server	 127.0.0.1 ; port 1234
;		root-dir "/home/dk/fcgi/"
;	]
] 

;rebol.si.org [
;	root-dir %//dev/si-org/old/
;	default %main.html
;	
;	redirect 301 "/mysql*" "http://si.org/rebol/mysql.shtml"
;	redirect 301 "/rebox*" "http://si.org/rebol/rebox.shtml"
;	redirect 301 "/"	   "http://si.org"
;]

; ###
; To add a new virtual host just duplicate and fill the following
; example host :
;
; my.vhost.com [
;	root-dir %/www/			; documents root directory
;	default [...]			; default files
; ]	
; ###

tried your package:

[uniserve] Async Protocol FastCGI loaded
[uniserve] Starting task-master...
[uniserve] Starting RConsole...
[uniserve] Starting HTTPd...
unknown-host

## Error in [uniserve] : On-received call failed with error: make 
object! [
    code: 311
    type: 'script
    id: 'invalid-path
    arg1: 'handler
    arg2: none
    arg3: none
    near: [either in port/locals/handler name: 'new-insert-port]
    where: 'insert-port
] !

seems that on your machine, the fastcgi client cannot connect to 
localhost:9999...strange, can you test this in console mode : >> 
read dns://localhost

content of windows/system32/drivers/etc/hosts file:

127.0.0.1       localhost
::1             localhost

- ping localhost works in shell window
- print read dns://localhost works in rebol
- change in mod-fastcgi did not help ...

A little update about the work in progress on Cheyenne's new version 
: I'm a little late on schedule (one week), I should release the 
new version tomorrow with several big improvements. The PHP/FastCGI 
final support involves some redesigns of mod-fastcgi that take much 
more time than expected. The good news is that it will result in 
a simple, fast and reliable interfacing with PHP. The other new features 
includes : text localization framework for RSP, support for any CGI 
scripts (including non-REBOL) and a new file upload system using 
temp files on disk (up to 2Gb files supported!). Once PHP support 
will be finished, I'll declare the first 1.0 release candidate (with 
encapped versions released too). I'll write all the docs during this 
debugging phase, so the completed 1.0 should be ready by the end 
of this month. I'm full time of Cheyenne starting from today, so 
it's doable.

Cheyenne new version 0.9.16 is ready. The new FastCGI multiplexed 
support took me some time to debug, but the resulting PHP interfacing 
is now really stable. I just need to update the RSP API doc and run 
a few tests, so the download link will be published here in a couple 
of hours.

Cheyenne release v0.9.16 beta. Download at http://softinnov.org/tmp/cheyenne-r0916.zip

Changelog :

v0.9.16 - 12/07/2007
	
	o Localization framework added to RSP. API overview :
	
		- #[text] in static parts of RSP pages will be translated.
		

  - new function: say "data" : translate a string! value in the current
		  language.
		  
		- session's new 'lang variable can set the current language.
		
		- new config file options to control default language and 
		  locales resources folder.
		

 o Decode-cgi rewrote from scratch. Cleaner and 2-3 times faster than 
 before.
	

 o RSP request params decoding rewrote. Now GET and POST parameters 
 are unified
	  in request/content.
	  
	o BugFix for encapping %misc/mime-types file.
	

 o File upload support redesigned. Now big files (user defined threshold) 
 are

   directly written to disk in temporary files, instead of being held 
   in memory.

   The temporary files are deleted once the request is completed. So 
   now

   Cheyenne supports files upload up to 2Gb (R2 port! limitation).
	  

 o CGI execution extended to any scripts (not just REBOL). If found, 
 the

   shebang line (#!) is honored (on all platforms). Several perl scripts
	  added in %www/ folder as demo.
	  

 o Module's 'on-started event now fired only once, when multiple HTTPd 
 instances
	  are listening on more than one port.
	  

 o New module : mod-extapp for launching and managing external applications.

   Only the start and shutdown actions are currently supported. Load 
   balancing
	  will be included in future.
	
	o FastCGI protocol reliability improved and some bugs fixed.
	
	o RSP-API documentation updated.

In theory, Cheyenne should be able to connect and pass requests to 
any FastCGI application, but it was only tested with PHP.

You can have more than one php-cgi process, but the pooling support 
is not yet implemented. For PHP, to control the number of threads 
(Windows) or processes (UNIX), just set the PHP_FCGI_CHILDREN parameter 
to the number you want. If you don't know what this is about, just 
leave the default value (1). Even with that value, it can supports 
dozens of concurrent requests (thanks to the fastcgi multiplexing 
support).

Hey Nenad, how does the following work?

;	extern fastcgi [
;		command	 "php -b $port"
;		pool 	 min 1 max 4
;		server	 192.168.0.100 ; port 1234
;		root-dir "/home/dk/fcgi/"
;	]
]

Terry: for defining a FastCGI app in Cheyenne, take a look here (PHP 
example) : http://softinnov.org/cheyenne/blog.cgi?view=0011

HOW-TO make Cheyenne work with PHP for non-Windows OS


The purpose of the following patch is to make FastCGI in PHP work 
the same on all OSes.


1) If you have PHP v5.2.1 or higher with sources, you can skip 2) 
& 3) else :

2) Download latest PHP sources from http://www.php.net/downloads.php
3) Untar the archive anywhere yo want
4) Go to PHP install folder
5) Patching PHP source :

	Open a REBOL console, then :

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][
	target: %sapi/cgi/fastcgi.c
	if none? attempt [buffer: read target][
		print "unable to find the file to patch!!"
		exit
	]
	either parse buffer [
		thru "int fcgi_accept_request("
		to "if (req->fd >= 0) {"
		pos: to end
	][
		insert pos "^/^-^-^-^-break;^/^-^-^-^-"
		write target buffer
		print "patch applied."
	][
		print "failed to locate the line to patch!!"
	]
]

patch-php
;---- end of code ----
		
6) Once the patch is applied :

	> ./configure --enable-fastcgi
	> make
	> sudo make install
	
7) Check if everything is ok :

	> php-cgi -h
	...
	you should see a -b option listed meaning you got proper
	FastCGI support.
	
	If it fails (occured on OSX), try with a full path instead :
	
	> /usr/local/bin/php-cgi -h
	

8) Edit Cheyenne's config file (httpd.cfg) to set the correct option 
in the PHP section. Non-Windows users have to also set the new 'delay 
option.

RSP framework will stay and will be improved. The new framework "X" 
will be an addition, so you will always have the choice to use whatever 
framework suits best your needs : CGI, RSP, "X", QM, or FastCGI engines 
(like PHP).

impressed! 8) I finally gave another try at php support in cheyenne 
and after patching fastcgi.c as suggested it now works like a charm.

If you are on os x and use macports, here is a way to patch and compile:

sudo port install php5 +mysql5 +fastcgi
sudo port uninstall php5
cd /opt/local/var/macports/distfiles/php5/
sudo tar -xjf php-5.2.6.tar.bz2
>> run patch below
tar -cjf php-5.2.6.tar.bz2 php-5.2.6
sudo port install php5 +mysql5 +fastcgi checksum.skip=yes

copy of Dockimbel's patch with path fixed for this example

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c 
if none? attempt [buffer: read target][ print "unable to find the 
file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" 
to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" 
write target buffer print "patch applied." ][ print "failed to locate 
the line to patch!!" ] ]
patch-php ;---- end of code ----