It thought the idea of proton was for the libraries and language API wrappers only. Why doesn't everything else just move into Qpid proper.
There is a danger that proton becomes its own AMQP project otherwise. No? Sent from my iPhone On Dec 18, 2012, at 6:54 AM, Ted Ross <tr...@redhat.com> wrote: > Yes, I'm looking for a place to contribute the server/container work I've > been doing. The candidates are qpid/extras or proton-c/contrib. Since this > work is really an extension of proton-c, it seems that the proton tree might > be the better candidate. > > Thoughts? > > The server/container code provides two APIs to supplement the proton-c engine > API. The server interface provides multi-threaded support for applications > using proton engine. It's features include: > > * Guaranteed non-reentrancy for specific connections > * Hooks for thread-based tuning (processor/numa affinity, etc.) > * OS signal handling > * Server quiesce/resume > * Incoming listeners and outgoing connections (resilient, with re-connect) > * Timers > * Integration with user file-descriptors (FDs used for purposes other > than AMQP) > > The container interface provides a means by which node types and node > instances can be managed. It allows application developers to write > node-type-specific handlers for: > > * delivery send, receive, update (disposition) > * link create, delete, writable > > The container allows static and dynamic provisioning of nodes. > > -Ted > > > On 12/18/2012 07:22 AM, Rafael Schloming wrote: >> Do you have something in mind to put there? >> >> --Rafael >> >> On Mon, Dec 17, 2012 at 6:08 PM, Ted Ross <tr...@redhat.com> wrote: >> >>> We've added a contrib directory under proton-j. Does anyone object to >>> putting one in the proton-c directory as well? >>> >>> -Ted >
