You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2012/12/18 00:08:25 UTC
Contrib under proton-c?
We've added a contrib directory under proton-j. Does anyone object to
putting one in the proton-c directory as well?
-Ted
Re: Contrib under proton-c?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1
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
>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
Re: Contrib under proton-c?
Posted by Ted Ross <tr...@redhat.com>.
On 12/18/2012 01:49 PM, Darryl L. Pierce wrote:
> On Tue, Dec 18, 2012 at 09:43:05AM -0500, 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.
> Are they artifacts that will ship _with_ Proton once they've baked?
>
That's a good question. I expect they would be bundled separately from
qpid-proton (i.e. in different RPMs for Fedora for example). The target
audience is, like Proton, developers who wish to use AMQP. But these
libraries would be used by developers wanting to build
higher-scale/performance intermediaries or clients that need to have
detailed control over the use of the protocol.
I guess it's ambiguous where it should live. I'm leaning toward just
using Qpid proper.
-Ted
Re: Contrib under proton-c?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Tue, Dec 18, 2012 at 09:43:05AM -0500, 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.
Are they artifacts that will ship _with_ Proton once they've baked?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Contrib under proton-c?
Posted by Rajith Attapattu <ra...@gmail.com>.
I also think qpid is a better place to host this than proton for the
reasons Rafi as mentioned.
However Qpid is fast becoming a collection of tools that are poorly
organized both on a source code level as well as on the product side.
I don't want to side track this conversation, but wanted to remind
that at some point we need to make an effort to work things at Qpid
level as well.
Rajith
On Tue, Dec 18, 2012 at 2:12 PM, Ted Ross <tr...@redhat.com> wrote:
>
> On 12/18/2012 02:06 PM, Rafael Schloming wrote:
>>
>> 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.
>
>
> I expect that in both cases, the proposed APIs will be looked at in detail
> so that their place in the world can be well understood.
>
> Thanks for all the input. I think I'll incubate them in qpid/extras. If we
> decide they should live in Proton, we can always move them. They will
> either move somewhere or die from neglect.
>
> -Ted
>
Re: Contrib under proton-c?
Posted by Ted Ross <tr...@redhat.com>.
On 12/18/2012 02:06 PM, Rafael Schloming wrote:
> 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.
I expect that in both cases, the proposed APIs will be looked at in
detail so that their place in the world can be well understood.
Thanks for all the input. I think I'll incubate them in qpid/extras.
If we decide they should live in Proton, we can always move them. They
will either move somewhere or die from neglect.
-Ted
Re: Contrib under proton-c?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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.
--Rafael
On Tue, Dec 18, 2012 at 9:43 AM, Ted Ross <tr...@redhat.com> 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 <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
>>>>>
>>>>
>
Re: Contrib under proton-c?
Posted by Ted Ross <tr...@redhat.com>.
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 <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
Re: Contrib under proton-c?
Posted by William Henry <wh...@redhat.com>.
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
>
Re: Contrib under proton-c?
Posted by Ted Ross <tr...@redhat.com>.
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
>>
>>
Re: Contrib under proton-c?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I would imagine it's for handy, non-core library bits. That proton-dump
guy would seem like a prime candidate to move in there.
On Tue, Dec 18, 2012 at 8:35 AM, William Henry <wh...@redhat.com> wrote:
> I too would like to understand what the contrib dirs under proton are for.
>
> Sent from my iPhone
>
> On Dec 18, 2012, at 5:23 AM, Rafael Schloming <rh...@alum.mit.edu> 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
> >>
> >>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
Re: Contrib under proton-c?
Posted by Ted Ross <tr...@redhat.com>.
William,
I see them as places to put new contributions so they can be developed
and evaluated while they look for a more permanent home.
-Ted
On 12/18/2012 08:35 AM, William Henry wrote:
> I too would like to understand what the contrib dirs under proton are for.
>
> Sent from my iPhone
>
> On Dec 18, 2012, at 5:23 AM, Rafael Schloming <rh...@alum.mit.edu> 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
>>>
>>>
Re: Contrib under proton-c?
Posted by William Henry <wh...@redhat.com>.
I too would like to understand what the contrib dirs under proton are for.
Sent from my iPhone
On Dec 18, 2012, at 5:23 AM, Rafael Schloming <rh...@alum.mit.edu> 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
>>
>>
Re: Contrib under proton-c?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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
>
>