Thanks Alan. On Thu, Mar 24, 2016 at 11:02 PM, Alan Conway <acon...@redhat.com> wrote:
> On Fri, 2016-03-18 at 16:01 +0100, Mark Banner wrote: > > I have gone through the documentation and code and have the following > > understanding of container vs connection_engine: > > > > Container is an adapter for pn_reactor. The proton reactor manages > > network > > IO and sends events to a registered handler so container registers an > > proxy > > handler which will pass events to the user's implementation. > > > > Connection_engine passes IO to a pn_transport (through io_read and > > io_write) and receives events through a pn_collector. Dispatching is > > then > > done directly to the user handler. > > > > From my understanding connection_engine looks more efficient than the > > container for the same functionality (if socket_engine is used). It > > also > > offers more control since a custom implementation can modify the > > event loop > > and mock IO for testing. This makes it a better fit for me compared > > to the > > proposed "application event injection" which is proposed in the > > thread on > > qpid-users. > > Am I missing something which is managed by the reactor or the > > container? > > That's an excellent summary. > > > > > Also, the release notes for proton 12 say that the API for container > > is > > stable but that connection_engine is still unstable. Will this > > interface > > still have the same role in future versions (ie converting IO to > > proton > > events) ? > > Yes. The connection_engine separates just the AMQP features of proton > without entangling them in any assumptions about IO or threads. It will > stay as an integration point for users that have special IO/threading > needs. > > The plan is then to layer more convenience on top of the engine for common > threading and IO use-cases, so users that are happy with a generic > implementation don't have to start from scratch. > > Injecting functions will be a part of the ease-of-use layer for the > connection engine, but injecting into a specific connection context rather > than a container of many connections. > > These are not untested ideas, they follow from patterns in the qpidd C++ > broker, the qpid dispatch engine and the proton Go binding. > > Cheers, > Alan. > > > >
