Decoupled ZMQ from Mongrel2 in Mongrel2Connection object

[sethmurphy]

Mongrel2Connection implementation now extends new abstract ZMQConnection. All code is the same as before, just re-factored. It is now possible to extend ZMQConnection to create non Mongrel2 based connections using ZMQ also. This was done in preparation for a BrubeckConnection for peer to peer Brubeck Instance connections also using ZMQ.

[sethmurphy]

This method of refactoring seemed to be the most backwards compatible way to decouple, but it does create an extra layer of hierarchy which could be avoided by using composition in the ZMQConnection instead by passing in a request object that could specific for the message format.

Does anyone think creating this extra layer of object hierarchy will be detrimental to Brubeck's performance? Performance should be the top priority in the connection layer.

[j2labs]

Hey Seth, I want to accept this. I haven't looked it since we last discussed. What is your current opinion?

[sethmurphy]

My current opinion, while useful, it creates too deep of class hierarchy.
It does need to be a class though, so since it instantiates only once that
may be OK.

As for the close method it was a pass and I left it as is. it would
probably be more proper to send an HTTP response. It may be best to leave
it unimplemented. Close has no real meaning and perhaps the programmer
should be responsible for sending a valid reason with send.

On Thu, Nov 29, 2012 at 10:19 AM, James Dennis notifications@github.comwrote:

Hey Seth, I want to accept this. I haven't looked it since we last
discussed. What is your current opinion?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/81#issuecomment-10850920.