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
