World: r3wp

(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

What i did with Framewerks is when a client logs in, I generate a 
random hash, and store it as a cookie, as well as on the DB associated 
with that user.

Logging in is good

Set the cookie to expire in 10 hours (log in once a day)

the application can automate if necessary

I have expiration in 30minutes if there is no action

On wirting modules, is this how it works: (?)
- create a mod-<name>.r
- start with install HTTPd-extension
- name 'mod-name

- order -> this I don't get but it controls the flow through mezzanines
 the rest is custom code


Q: what other data is available in a mod and what is the order thingy?

I associate the the IP with the user a well.. if the IP is a mismatch, 
the cookie is void

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.

thanks.. I was just trying to run the php test but it fails.. so 
I was asking

php test is working, let me see if there's no regression in last 
release...

If there will be possibility to run php from cheyenne, I could stop 
using apache at home for testing

What's the issue with windows cookies? .. if there's a timezone difference, 
can you not adjust the expiration accordingly?

Not accurately on Windows platforms due to REBOL inability to handle 
local summer time (daylight time saving period).

Well, can still set it generally, no?

20 mins may not work, but 20 hours give or take should

The workaround is to call directly the win32 API to get the correct 
timezone offset, so requires /Library component.

sure, 20 hours would not be an issue ;-)

Or, you could ask for the TZ?

Although that's a bit nasty.

Oldes: I've stopped using Apache locally to run php apps (like phpMySQL) 
since 2 weeks ;-).

I was running PHP fine.

Terry: I'll provide an option in the next release to add session 
cookie expiration time, but will be "at your own risks" ;-).

speaking of PHPMySQL.. that piece of software is begging for an upgrade.

phpMySQL => phpMyAdmin

how about regular cookie expiry?

yeah.. that's what I meant too ;)