when I should have been working, I have been sneaking peaks at the code.
I'm trying to get a feel for the handler invocation logic. Now I will
admit I haven't spent much time in that code. So please read all the
way through before answering.
looking at how the configuration file implies behavior, when you match a
series of predicates (combination of server and directory) you derive a
working document root and invoked a list of active handlers (server wide
and directory wide?).
question: based on what I have stated I want to do, how difficult
wouldn't be to add the ability to trap and execute something (CGI, etc.)
on additional predicate terms such as a 404 and then pass control to the
system 404 handler if all the alternates fail? you actually implement
this as an implied behavior for DirectoryIndex. In that context to give
a list of alternatives and as each one fails you move to the next one.
Generalizing that could be amusing (or very painful).
the list of methods executed by a handler are defined (as far as I can
tell) in handler.c. Is this a C version of an abstract class?
these first two look like they are some form of default case in case the
specified handler doesn't do what it should.
ret_t
cherokee_handler_init_base (cherokee_handler_t *hdl, void *conn)
ret_t
cherokee_handler_free_base (cherokee_handler_t *hdl)
looks like this should be overridden to free up any handler specific
resources use.
ret_t
cherokee_handler_free (cherokee_handler_t *hdl)
initialization of handler. Question: how does one pass arguments to the
handler? For example, I'm seriously thinking about creating a python
handler and I would want to pass with the handler the path to the python
program. How I get that path? would the path be fully qualified for me
or is that something I need to do manually? when is the init handler
called?
ret_t
cherokee_handler_init (cherokee_handler_t *hdl)
the only thing I can think of for this little function is about adding
headers to the output stream heading back towards a browser. But
looking at the CGI handler it looks like it's also copying data as well.
it also looks like it's an iterative process returning buffers of data
to the browser until the CGI program runs out of data.
ret_t
cherokee_handler_add_headers (cherokee_handler_t *hdl, cherokee_buffer_t
*buffer)
slightly confused here. It looks like this is also a return data by
blocks method but it seems to not be concerned with headers so I'm
guessing my interpretation earlier was incorrect and that the
add_headers method returns headers until it gets "data". The data is
stored in a temporary buffer until the step method is called and then
the rest of the data is shuffled out. close?
ret_t
cherokee_handler_step (cherokee_handler_t *hdl, cherokee_buffer_t *buffer)
now remember, I haven't touched C code for ten years and my hands are
broken so the odds of this happening are really not good. But if I was
to try and embed python, is this a threaded environment? If so, what's
the right way to surrender control of the thread?
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
