World: r3wp

Another way to put it.. I want to map all urls to a single module

Terry: use the 'filter-output phase to catch all 404 (you can implement 
it in mod-static, or in your won module).

won = own

any specs on that phase?

all phases use the same func spec block, this one will be called 
just before the response is sent to the client.

Also I tried a make-response phase in  a module, but it never fired?

more info in %docs/developer-guide.html

yeah.. I got to this part.. 

Here's a typical phase implementation :

url-translate: func

:)

http://www.compkarori.co.nz- userid dockimbel pass 1234

not crashing at the moment

doesn't do much except authenticate and produce a menu

If your 'make-response is not fired, it's because another module's 
'make-response did get called and closed the phase. You should also 
turn on debugging using -vv option when starting cheyenne.r, it will 
show you which phase from which module get called, so you'll see 
who's the guilty one ;-)

Graham: testing, seems ok so far.

I'll play some more .. but I have been avoiding redefining global 
words :)

and change it's return to false, i take it.

which modules do I need to include for stripped down cheyenne?

right: FALSE will let other module a chance to process the phase, 
TRUE will close the phase.

mod-static (static pages), mod-action (CGI)

and mod-rsp if you want RSP engine.

so.. looks like static returns true?

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

Ok.. .. so .. what's up with the first normal last?

humm, not sure you can infer the resulting phase value from that 
log (might be TRUE or FALSE, but not NONE)

So, does Cheyenne process all modules phases then moves onto the 
next in all modules?

kinda parallel?

first / normal / last : that's the position in phase list, you'd 
like for your function in a given phase

in other words.. do all url-to-filename for all modules.. then do 
all set-mime-type for all modules... and so on.

Right, one phase calls all modules (unless one returns TRUE), then 
go to the next phase (see the 1.1 in developer's guide).

exactly

ahh... ok...

that's pretty cool...

why does the position matter?.. is the position related to other 
modules, or to itself?

the position determines the calling order in a given phase

I take it the module order in the config file is a type of position 
as well?   if the tirst module returns true, then the rest not considered?

when you declare : url-translate first, you want your module's url-translate 
to be called the first.

but if phases are in order, why not follow the order?

exactly, modules are competing to close each phases, so order in 
the list, and order in config file matter.

I can see how that could be a bit tricky.. somewhat bug prone

if 2 modules declare the same phase's function to be first, which 
one to call ? :-)

this case is solve only by the position in config file.

Need some kind of global phase viewer

(sounds like a module :)

normal then is pure config order

This system is very flexible, but if not carefully done, can lead 
to a messy organization. I plan to move to a more simplified system 
(but more restricted too) for Cheyenne 2.0 (not before 2008, I guess).

This is fine.  just need to grok the system better.

That helps alot, thanks

Graham: still no crash on your server

true

(sorry, wrong channel)