World: r3wp

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
] !

ahh ok.. need to run embed-demo.r rather than cheyenne.r.. working 
fine now

very very cool.. perfect for this current project

This is somewhat historic imho.  Embedding a full featured web server...historic.

Well, you could do this with Uniserve long ago.. just not with such 
ease and organization.

trailing slashes seem to play an important part.. will this be an 
issue with improperly formed urls?

cookies still not working with xp ?

Ok.. sessions work if i use 127.0.0.1 rather than localhost

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
]
>>

Needs rebol/view ???

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

in cheyenne.r:
- if unset? 'do-events [do-events: does [wait []]]
+ if not value? 'do-events [do-events: does [wait []]]

must be a mistake

instead of using do-events, just use wait []

do-events == wait [ ], the docstring inside do-events func spec is 
not accurate, it should be "Process all events".

Woha!

(that's a compliment ;-)

Archive re-released with a fixed test for 'do-events.

2 questions: will you combine this with nysql:// ? I would like the 
session management to be databse driven so that load-balancing becomes 
easier?

*mysql://

hum, it should be possible to store session data in DB, but you'll 
loose performances compared to keeping it in memory (it's stored 
in Cheyenne's main process).

what kind of load-balancing architecture do you have in mind ?

multiple web servers with sessions and database driven content. So 
based on the session ID i generate personalized content

If the session ID is persistent in a DB any Cheyenne can handle the 
request

Ideally, you can configure the session mgt backend in httpd.cfg

Other question: how do I create a friendly URL mapping in Cheyenne? 
using the publish-site dialect?

(hope I'm not too demanding, just trying to match Cheyenne against 
a lot fatures I use in my projects)

If you're using Cheyenne in embed-mode, 'publish-site let you define 
whatever URL mapping you want. In standalone Cheyenne, there's no 
general way to define URL mapping, it's currently up to each module 
(CGI, RSP,...) to handle their specific mappings. I'm hoping that 
the future mod-rewrite will allow efficient and general URL mapping 
(there's a mod-rewrite published by Will, who could already do that).

I think that embedded mode might be the killer. Especially if you 
can combine it with encapsulation on a virtual file system

Is there a module writing 101?

About the DB stored sessions shared across multiple Cheyenne instances, 
it would require a significant change in the current way session 
data and especially, session synchronization is handled (currently, 
it relies on semaphores and queuing to achieve that).

OK. The other option is using a load balancer that support sticky 
sessions

Encapsulation with virtual file system : that's planned for next 
week ;-)

And how it's with php and fastcgi?

But... also for fail-over it is nice to have it databas driven

OK. Although I must say that on second thought for serverside softwware 
encapsulation isn't that interesting

I agree, sessions need to be stored somewhere on disk for fail-over.

Not just session... user passwords as well

And credit card numbers!

:)

Yeah, and sessions are fine if you don't mind logging in everytime 
you open your browser

Terry: do you mind?

?

What, Im Trolling again?

No! I meant : do you mind logging in every time....

And if so, what do you prefer and how do you solve it.

ah ;)  yeah.. its a hassle

Terry: I may add an option to make sessions persistent on client-side, 
but that require cookies with expire time, means failing again in 
REBOL timezone issues...

Funny, I consider it basic security

me too