httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabio Kaminski <fabiokamin...@gmail.com>
Subject Re: modules architecture issue
Date Wed, 15 Sep 2010 21:21:10 GMT
Hi Nick, thanks for answering..  im reading your book and surfing some
apache code for hacking.. it has been a nice trip
.. and your book is very rich of knowledge! (without it.. only hacking the
code :s) so thanks for that :)

i've done some nginx modules coding too, and apache it's way more productive
and more tuned for app development, the the apr lib it's a great achievement
also..

so, i saw that filters has a good flow mechanism, and since the bytes can be
handled like a stream, i think it would be better to handle and parse that
as they are coming into the channel..

but since i started this 3 days ago.. and i will not pass a huge amount of
data.. i think parsing in the handler with the data ready will be fine.. not
too much to loose there.. (but i like the modular way apache is.. and will
do that in filter when i mastered apache a little more)

i think now my worries will be focusing the db pooling of connections.. and
i will study the db modules a little bit more to understand how it its
done.. (its not a sql db)

thanks for the anwers again..

Fabio

On Wed, Sep 15, 2010 at 5:52 PM, Nick Kew <niq@apache.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message