perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Werner <>
Subject Protocol Philosophy
Date Fri, 03 Mar 2006 15:29:01 GMT
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. 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

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? 

Making things work is not a problem. I can always make things work. What is
the prevailing wisdom as to how things should work?

Thanks in advance, and kudos for a well built tool,
Christian Werner

View raw message