httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <...@apache.org>
Subject Re: modules architecture issue
Date Wed, 15 Sep 2010 20:52:13 GMT
On Wed, 15 Sep 2010 14:57:25 -0300
Fabio Kaminski <fabiokaminski@gmail.com> wrote:

I'm not certain I understand the question, but here goes ...

> and at least for data, i thought use something like  [input filter ->
> handler -> output filter]
> 
> where the input filter receives a formated string and parse into a internal
> object struct.. the handler get it
> and using a rest mechanism (put,delete,get,post) in the handler..

An input filter doesn't strictly speaking asynchronously with your handler,
but conceptually you should think of it as asynchronous.  If that fits
your application well, go right ahead.  Otherwise it's probably going to
be easier to do all that within your handler.  The exception to that is
if you have functionality that becomes re-usable across multiple
applications if you put it in a filter.

> the handler then call a db api, for the data operation.. and if is something
> like get.. the output filter decode our internal object struct into
> the formated string..

That sounds like it should be just fine running asynchronously.  But using
a filter may still call for more groundwork.  Ideally you should create a
new bucket type for your internal objects to pass them down the chain.

> i saw the smart filter, but couldnt fire it.. since i didnt see a example
> module using it..

Smart filtering is a matter for configuration.  If your application
requires the filters, it should probably manage its own configuration.
If the filters are optional then by all means leave it to the sysop
and recommend using mod_filter in your documentation.

-- 
Nick Kew

Mime
View raw message