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 <n...@apache.org> wrote: > On Wed, 15 Sep 2010 14:57:25 -0300 > Fabio Kaminski <fabiokamin...@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 >
