Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…


Cannot retrieve contributors at this time

file 48 lines (41 sloc) 1.531 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

ruoso suggestions:

1) receiving a request
that's the "engine" part
it knows how to be triggered for an event
and generates a "Request" object
I, for one, think that should be able to handle the engine part standalone if it has to.
in Catalyst the "Request" object is very HTTP-specific
this is something that can be fixed
you can have a much more generic "Request" role
and have a HTTPRequest role to complement it
this "Request" object is the thing that takes us to the second step

2) dispatch
This takes info from $req in order to dispatch
I think the generic request role would provide
has $.uri
has %.params
The mistake in Catalyst in the dispatch part
is to make each dispatch type independent
like it first tries to dispatch "Regex"
if that fails
it tries "Chained"
if thoat fails "Path"
you need a way to provide an unified dispatching
I think the good way of doing it is basically to consider everything "Chained", while support different part matching algorigthms
the third step is actually having no third step

and ruoso again:

1) the engine code is something external that declares $*request and $*response
where you have generic Request and Response roles
ihrd: there certainly doesn't seem to be a shortage of ideas, at least :)
but also specific Request::HTTP and Response::HTTP
or even
Request::Apache and Response::Apache

2) the dispatch code is something that tries to match an action using $*request
takes that action
calls $action.begin
and that's all
Something went wrong with that request. Please try again.