World: r3wp

but mods have a special loader, so if you want to reload a changed 
module, you need to unload the previous one and do some internal 
cleanup in Cheyenne. This "unload and cleanup" part need to be implemented 
to be able to reload an active module. OTOH, loading a new module 
could be done right now without any issue (remains untested).

Graham: yes, RSP and Session support is fully working, but you should 
consider it beta state.

unload is easy... its the cleaning up part ...  ;)

I didn't had much time to work on an internal API for live changes 
in Cheyenne, but, in theory, you should be able to reload the entire 
Cheyenne and Uniserve engine without restarting and without loosing 
opened connections.

is the clients URL in the req/in/headers  ? tried printing the headers 
to the console, but chokes on the HOST?

oh really.. interesting

This kind of  "change in live" stuff is still experimental.

probe req/in instead

um, which phase contains the clients ip address?

Phases are just stages in the request pipeline. If you need client 
IP, from one of the phase handlers (like url-translate, for example), 
it's in svc/client/remote-ip (svc/client point to the client port! 
value)

Terry, btw, i've just tested again /testapp/sixteen.html in FF and 
IE7 on different PC (XP sp1 and sp2), I can't reproduce the problem.

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

Good idea, thanks for the link.

Graham: yes, RSP and Session support is fully working, but you should 
consider it beta state.

  - that's no problem, the mysql driver was beta quality for years 
  ;-)

... it was actually marked as beta, in fact it was 2.0 from the very 
beginning :-)

Or "Vista" depending on your company's quality standards ;-))))

Any chance to integrate RebServices CGI mode in a way that keeps 
RS stuff running? So something like a fake CGI?

That would be killer environment.

Do you mean tunneling Rebservices through HTTP ?

Doc, When the Cheyenne version is released will it be announced here 
http://softinnov.org/cheyenne/blog.cgi?

Sure

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.

Ok.. Doc.. trying to make a mod called my-mod


In the mod folder i create a file .. my-mod.r  that has this code. 

rebol []

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

	order: [
	url-translate first
	]
	
	url-translate: func [svc req conf][	
	probe svc/client/remote-ip
	print "test"
	]
]

I added my-mod.r to the %mods/ [ .... block in cheyenne.r
Doesn't fire?

Took out the print statement, added to the mod-rsp.r module, ... 
in that module i added url-translate first.. and works fine.
Is it not seeing my module?

Terry you need to put a none after print "test"

or a logic

the function need to return a value

if you need one more example, here the mod-rewrite:

http://reboot.ch/mod-rewrite.r

ok.. made some changes...  renamed the module: mod-my-mod.r   .. 
added this to the http.conf file

Working fine now. (and the none after print "test" allows the print 
statement to work as well)

that was rather painless.

and well organized.

So I removed the module from cheyenne.r and it works.. I gather that's 
just for encapping?

Cheyenne is very extensible... shoud be easy to build http based 
file uploaders, advanced logging... db connections, advanced file 
mapping, authentication, mod-rewrites without the regexp.. tons of 
stuff.

Terry, I'll provide some better docs about modules creation and a 
step-by-step example on how to build simple module.

Why not runniong the RSP bugtracker of Cheyenne to track the bug... 
of cheyenne ?
Like this, it's a live and usefull Demo !

Dock said he will use it on softinnov and also release the source 
as a complete rsp example, probaly not yet ready for "beta" 8-)

robert, yes to integrate rebservices as a 'cgi access module' (bridge)

which provides e.g. a persistent connection to sqlite or rebdb etc. 
would 

be nice. could be also used as a starting point for a nice webbased 
admin-concept for sqlite.

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

No, I did not, because I thought it requires special handling in 
the CGI prog.

in cgi compatibilty mode, the only problem you can have is if the 
cgi script is not reentrant, but services should be.

Something in Cheyenne preventing the -s security switch in WinXP 
?  I get  the "encap-fs.r requests permission to open port" security 
message.

Is there a release somewhere that I'm missing and evrybody else *did* 
find?

Didec: I need to finish to CSS code to put the bugtracker online, 
it will take me a few hours of works, so I put it online this  weekend.

Is Dockimbel short for "Documentkimbel"?

Terry: I run it on XP with the following command-line : rebol -s 
cheyenne.r, no security requestors here.

nope, doc is for doctor ;-)