The proton-j/contrib directory was created to hold glue/integration with
established third-party libraries/apis (specifically jms and hawtdispatch).
The fact that hawtdispatch and jms don't want a proton dependency, and
proton doesn't want a jms or hawtdispatch dependency kind of forces the
glue/integration to sit somewhere separate from each, and since it is kind
of silly to have an entirely separate project just for that
glue/integration code, creating a proton-j/contrib made sense. I wouldn't
be opposed to a proton-c/contrib for similar purposes, however what you're
describing sounds different. I'm assuming these libraries have no issue
depending on proton, which makes this use of contrib a kind of incubation,
which begs the question, what is the intent for this stuff once it's
hatched? Is the idea to provide another layer to the proton library itself,
or to provide something that is really an independent library with a
different focus?

If the former is the case then I think we should probably be taking a
careful look at the proposed APIs and understanding in detail what they are
and how they build on what is already there (i.e. not just shoehorn it into
contrib), and in the latter case I would say we should keep incubation to
qpid proper.


On Tue, Dec 18, 2012 at 9:43 AM, Ted Ross <> wrote:

> Yes, but the content I'm talking about is just libraries (and headers).
>  Actual applications like routers, proxies, brokers, etc. would live in
> Qpid.  I can put these libraries in qpid/extras just as easily.  That's why
> I'm asking the question.
> -Ted
> On 12/18/2012 09:29 AM, William Henry wrote:
>> 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 <> 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 <> wrote:
>>>>  We've added a contrib directory under proton-j.  Does anyone object to
>>>>> putting one in the proton-c directory as well?
>>>>> -Ted

Reply via email to