Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <F06B470F635BE045B7D43B21A466903101D0DD17@rccs4.intrcc.com>
From: Chris Werner <ChrisJW@unicel.com>
To: modperl@perl.apache.org
Subject: Protocol Philosophy
Date: Fri, 3 Mar 2006 09:29:01 -0600 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C63ED7.32AA1B5C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C63ED7.32AA1B5C
Content-Type: text/plain;
	charset="iso-8859-1"

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

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


------_=_NextPart_001_01C63ED7.32AA1B5C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>Protocol Philosophy</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Mod_perl list,&nbsp;&nbsp; Apache =
2.2.0 mod_perl 2.0.2</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.&nbsp; I have read the provided docs, copied, =
executed and modified the examples.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">That is my best understanding of how a =
protocol implementation should be constructed... </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As the provided examples show, work =
can be done, for example, in the FilterHandlers.&nbsp; 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? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Making things work is not a problem. I =
can always make things work. What is the prevailing wisdom as to how =
things should work?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks in advance, and kudos for a =
well built tool,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Christian Werner</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C63ED7.32AA1B5C--