qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject C++ architecture and refactoring.
Date Tue, 16 Jan 2007 15:37:11 GMT
As part of the 0-9 work I want to do some refactoring to clarify the
architecture and separate concerns a little better. I think it's a good
opportunity to discuss architectural principles. Comments welcome! I'll
write up a wiki page when the ideas have settled.

= Qpid C++ Architecture = 

* network layer (qpid::sys::*): IO abstractions, network handling 

*framing layer (qpid::framing::*): encode/decode, generated from spec.

* adapter layer (client/broker::*HandlerImpl): Adapts framing APIs to
calls on core objects. Sends frames to peer via the Proxy.

* broker/client core (client/broker::*): Main functionality

This architecture is already implied by the code - you can see how the
namespaces & class names line up neatly with the layers. The bit that's
murky right now is the adapter/core distiction. Broker side
SessionHandlerImpl and it's inner classes do a bit of both. I plan to
pull the core broker functionality out into 3 main classes: Connection,
Channel and Broker. That will leave a set of light Handlers that just
 * simple argument manipulation
 * delegate to the core
 * make calls on ClientProxy.

In particular the handlers for per-channel classes need access to the
right Channel object so I'll change the signatures to take a Channel&
rather than a channel number. 

Apart from helping the 0-9 work I'm doing now I think this will help
prepare us for multi-version support. Basically I see us generating
separate framing classes for each version in the framing layer and
writing adapters for each version that delegate to the same core
classes. I think there may also be scope to partly
automate/codegen/templatize the adapter layer so we can keep the
hand-coding to a minimum. 


View raw message