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.
