for now I have only skimmed your post, but from what I've seen I want to encourage you to follow the stony path to a clean and solid implemetation of URL mapping and parameter validation - a common dispatch language for web applications so to say, which covers most (if not all) eventualities and flavours of requests.

This is one area of web programming which AFAIK ever since has been buried in frameworks, and decisions were made upon implementation by mere gusto or style or design inclinations than by actually pursuing a path which adheres closest to the perl way (or more perl ways than one) of seeing things.

Thanks for bringing up this question. I would consider it rather a meditation since it's a topic to meditate upon, and not just answer. I'll append my thoughts here as soon as I have time - have to get that train.

update

Sorry I'm thinking aloud here, and most of this might have passed through your mind during this day, I've seen your thoughts evolving from the sparse comments in the CB. Lets first name some things before even thinking of any language.

The big problem in URL to perl function mapping is TIMTOWTDI, a strength of both perl and fools. While virtually any programming model can be achieved with perl by including nifty packages (think all the Class:: stuff around, which gives us reflection, function propagation through inheritance chains, private and public class stuff, attribute handling etc), I would encourage an implemetation path which adheres closely to the perl core, which doesn't preclude any implemetation flavour you might choose for a particular task or programming paradigma.

Perhaps it might be helpful to examine and classify the bunch of information given by a HTTP request, and compare its elements to perl thingies.

Oh, wait... that would lead to a naive approach, such as translating a PATH_TRANSLATED eq /root/some/foo/request?foo=bar to Root::Some::Foo->request(foo => bar) inside an application (or calling of methods w/attributes).

But the parsing requirement might be totally different, key/value pairs of the QUERY_STRING might elect (or constrain) the function to dispatch (or reduce the dispatching possibilities). Path elements might be used as parameters (think of a request like /foo=bar/quux=blorf/what?nothing) and then there might be requests like /foo/1 /foo/2 /foo/3 which resemble a server side stored history of requests which are further parametrized e.g. by cookies or encryption keys and walkable to and fro.

Order of parameters might matter; the QUERY_STRING could resemble a chain of methods/functions/whatever called in order with (equally?) named parameters. Part of an URI could be one or multiple keys used for decryption and/or database lookup, session key and so forth. While there surely are Best Practices[tm], anything is possible.

So, to get at something generic, the least common denominator for all possibilities must be found, and since even the least common denominator is not known, it must be configurable.

This sounds much like either a) a tree or b) a dispatch table ... oh wait. Same naive approach as above.

There's a least common denominator in each handling method of URI paths and QUERY_STRINGS. May be more than one. I.e. there's always something of any type that will be checked first, maybe against a set of posibilities, which might be ordered in importance or not.

So, your approach should provide for

• a way to set up a grammar in URI/QUERY_STRINGS handling
• iterative matching / processing with and without execution order
• (non-)destructive pipelining of matches

(to be continued..)

cheers,
--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}