World: r3wp

CGI environment is not supposed to be persistent, so there's no other 
ways than to manually add libs loading code to %CGI.r script. If 
you're encapping Cheyenne, you can add your libs to %cheyenne.r (and 
don't forget to LOAD them too). If you need a persistent environment, 
use RSP instead.

Thanks for the 'NT-Service? fix, it will be included in the next 
release.

Think we might try using Cheyenne as a personal web server, providing 
functionality similar to Adobe Air, Google Gears for our product.

Here's a little video clip of a prototype in action.. 
http://kommonwealth.com/video/cheyennewidgetdemo.swf

That's all taking place in the browser, being served up from our 
server.. and accessing a copy of Cheyenne running locally. No cross-domain 
issues here :)

Firewall problems? You have to allow listening port ... but - that 
should not be problem for 99% of users imo ...

Flash has very strict security. You have to setup it correctly to 
anable cross-domain functionality. It's not bad if you understand 
how it works.

It has nothing to do with Firewalls.

http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf
(but it's not related to Cheyenne)

Basically it's the part which was showstoper for Rebol plugin - shortly 
it works in a way, that if you want to connect to some site with 
Flash, Flash first loads crossdomain.xml file from the target server 
where must be your domain allowed to access the server domain. If 
it's not allowed, the Flash do not connects at all. It's a basic 
prevention of doing Dos attacks from Flash Player.

I'm not sure what is Terry doing, but of course you can use Rebol 
to connect from Flash to services on servers from not allowed domain 
as with Rebol you can change the request header easily.

what are you talking about, Oldes? And yes, it has something to do 
with firewalls. The thing is - noone was talking flash here ;-)

Terry imo wants to use Cheyenne as local web server, and to allow 
their kommonwealth to run locally cached, or something like that 
- but still - his technologies are html, css, js, ajax ....

yeah, Pekr's right.  There's no flash there. 
I suppose the firewall would be an issue for some.

DocKimbel, small request: Would it be possible to post the rsp guide, 
cheatsheet and docs as separate pages directly on the site? It's 
unpractical to have to download Cheyenne every time I switch machine, 
just to read the docs. Thanks.

stick them on google as a googledoc :)

Henrik: good suggestion

RSP API document now online at : http://cheyenne-server.org/docs/rsp-api.html

cool

Cheyenne Wiki is online : http://cheyenne-server.org/wiki.php

It's running on the latest version 0.9.19 (not yet released) with 
php 5.2.6.

The wiki engine is PmWiki.

If you want to contribute by writing docs for Cheyenne, please ask 
me privately for an account.

Pretty neat demo of php in action with Cheyenne

Yep, it's quite fast, but will be faster when the FastCGI code will 
be optimized.

can cheyenne be used to spawn a new task for a 3rd party application?

Yes, that's the purpose of mod-extapp.

It has been improved in the upcoming Cheyenne release (0.9.19).

Mod-extapp can launch and kill 3rd party apps automatically.

My EMR has to do things like play back speech files etc, but I can't 
do it inside the app as it will kill the async.

So, at present I'm using the mini webserver to play back sound and 
do voice recording.

Well, looking forward to new release then :)

You could rely also on Uniserve's task-master to execute blocking 
tasks.

Do you have examples of this?

Ahh... it's in the FAQ section :)

There's some unfinished docs for building "modules" for task-master, 
http://www.softinnov.org/rebol/task-master.html

See 6.Module API

Basically, it's just :

REBOL [...]

install-module [
    ...
    on-task-received: func [data][
        ...
        response: ...
    ]
]

ok

You can look at modules/CGI.r for an example.

I've added a url-aliasing feature to Cheyenne, so now the wiki will 
be more search-engine friendly. The new URL for the wiki is http://cheyenne-server.org/wiki

Excellent

very nice wiki site

just one small point, characterizing indians is not really considered 
correct, though i like your image and he is smiling.

I agree, I was planning to change the baseline since a while.

Calling them "Indians" is not correct either.. if you want to be 
judgemental.

Although the 'cartoon' looks like my mom... seriously.

don't want to be judgemental just saying...not a big deal, but note 
that Apache uses the feather, far more neutral

Is there anything that would cause Cheyenne to crash? I've not yet 
tracked down the bug, but every time I click a specific link on one 
of my .rsp pages, it just dies and needs to be restarted. Unfortunately 
it's now gone so far that it seems not to want to serve pages anymore 
even though it's running. Under OSX, I get this log output:


Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68212 PPID 68210 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68211 PPID 68209 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68210 PPID 1 
rebol

Aug 20 23:31:16 Macintosh com.apple.launchd[136] (com.rebol.cheyenne[68207]): 
Stray process with PGID equal to this dead job: PID 68209 PPID 1 
rebol


Are there any file permissions, that if set wrong, would cause cheyenne 
to stop serving pages?

variable overvrite?