FAQ

Chris Werner wrote:
You lost it here, Chris. Input filters feed the protocol handler, not >
the other way around.

Maybe, but that's why I ask questions... Now read what you write:

... the protocol handlers simply ask the last input filter to give it >
data ...

Still, the protocol handler creates the BB object that the input filters
populate.

And the filter populates that data in the BB created and supplied by the
protocol handler. Or can a filter create a BB on it's own and somehow manage
to get that data to a protocol handler that does not create a BB?

I think the confusion here is the difference between data flow and object
creation and data request. Perhaps you would be so kind as to spell out your
best understanding of these topics?
Exactly. The limitation is due to the design of the filter stack/code.

Pretty much all I've learned about http2 filters is explained here:
http://perl.apache.org/docs/2.0/user/handlers/filters.html

The particular question of flow/data is explained here:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Blocking_Calls

You're more than welcome to try to improve the documentation if you find
it confusing. Just ask questions, get the answers and then make the docs
more clear.
Certainly. Take SSI for example...

OK, now there is an example of a filter complex enough to warrent state
machine logic... considering that I am cerian there are others. I would
still ask: Is decoding an encrypted stream doing the work of the protocol
implementation?
Yes and no. You could do it in the protocol, but it's not the right place,
since it requires that you change the logic of your app to do something
that it shouldn't be really doing. mod_deflate for example does
compression and decompression of the data - why would you complicate the
logic of your application (i.e. protocol handler) to do this thing? A
filter is a perfect location for this. It's also more efficient, since it
does the most efficient chunking and buffering.

I think http://perl.apache.org/docs/2.0/user/handlers/filters.html talks
quite a lot about the reasoning for using filters, I agree it's a huge
document so you may need to read it more than once before you can grasp it
all. It took me a very long time to wrap my head around it.
... what if your ...[output?]... files live in a database?

Sure, then the protocol handler passes a token to the output filter which
looks up the proper response, and passes the contents out. A valid example
of a data base lookup in a filter, but not exactly what I was referring
too...
OK, mind to refine your question?
TIMTOWTD...

???
TMTOWTDI=There's More Than One Way To Do It


--
_____________________________________________________________
Stas Bekman mailto:stas@stason.org http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
groupmodperl @
categoriesmodperl, perl
postedMar 3, '06 at 3:28p
activeMar 10, '06 at 12:26a
posts4
users2
websiteperl.apache.org

2 users in discussion

Stas Bekman: 2 posts Chris Werner: 2 posts

People

Translate

site design / logo © 2017 Grokbase