FAQ

Chris Werner wrote:
Mod_perl list, Apache 2.2.0 mod_perl 2.0.2

I have been working with an alternative protocol implementation for apache
for some time now and [as would be expected with a perl based tool] I have
found many ways to accomplish the same task. I am asking about the
philosophy or design intent of these filters. I have read the provided
docs, copied, executed and modified the examples.

My best understanding of the intent is that the PerlProcessConnectionHandler
sets up the connection, and issues a request to the PerlInputFilterHandlers
for data. The PerlInputFilterHandlers gets the raw data in a bucket
brigade(s) and have first crack at massaging the data. Here we handle data
overrun, underrun, and reorder bucket (and brigade) contents to have
reliable contents. The PerlInputFilterHandlers do not send this data
downstream per se, instead they respond to requests for incoming data from
downstream and answer these requests by manipulating the bucket brigades
supplied by the PerlProcessConnectionHandler.
You lost it here, Chris. Input filters feed the protocol handler, not the
other way around. It's actually very simple - w/o any filters the protocol
handler read from the network and writes to the network. If there are
filters they get a chance to modify the data that streams through them.
sometimes a filter may decide to buffer the data and not let it through
until later but filters and protocol handlers work independently: the
protocol handlers simply ask the last input filter to give it data and
that filter propogates that request to the next input filter and so on,
till the network is reached, then the data flows back to through the whole
chain of input filters till it reaches the protocol handler, each filter
sees only a chunk of data at a time (normally not more than 8k). when the
protocol handler wants to send data out, it just passes it to the first
output filter, which then passes it to the next output filter, and so on,
till the network is reached. again only a chunk of data is sent at a time.

The
PerlProcessConnectionHandler does the work of implementing the protocol;
here state machine actions and database accesses are performed. The
PerlOutputFilterHandler fills out bound bucket brigades with outbound server
side protocol messages.

That is my best understanding of how a protocol implementation should be
constructed...

As the provided examples show, work can be done, for example, in the
FilterHandlers. What was the original intent? Is there ever a case where it
would make sense to perform database queries/updates or hold state machine
logic external to the data stream in a FilterHandler?
Certainly. Take SSI for example, what if your files live in a database? In
the case of PHP - they can run both as protocol handlers and filters, so
for example you could have a mod_perl handler whose output is then
processed by a php filter. As you can see you can mix and match different
languages and re-use existing solutions, w/o reimplementing things in your
favorite language.
Making things work is not a problem. I can always make things work. What is
the prevailing wisdom as to how things should work?
TIMTOWTD...

Perhaps you should explain what exact issue you are having with the
protocol/filter handlers, so it'll be easier to explain :)


--
_____________________________________________________________
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

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 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