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
>
>
+1
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
>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchir...@redhat.com | fusesource.com | redhat.c
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 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 dire
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 wrote:
> I too would like to understand what the contrib dirs under proton are for.
>
> Sent from my iPhone
>
> On Dec
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 prov
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 1
[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey reassigned PROTON-136:
Assignee: Philip Harvey (was: Ken Giusti)
> Add support for SSL session resumption
> -
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 lo
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
[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534937#comment-13534937
]
Philip Harvey commented on PROTON-136:
--
It's not clear to me whether I need to make c
[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13535024#comment-13535024
]
Ken Giusti commented on PROTON-136:
---
FYI:
Updated the reviewboard with the latest patch
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 th
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/in
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/extr
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
On Fri, 14 Dec 2012, Rob Godfrey wrote:
A couple of comments...
On 13 December 2012 23:37, Justin wrote:
API usability is important and deserves attention.
pn_link_drain
Existing C name:pn_link_drain
Proposed C name:pn_link_rescind_credit
Existing Java name: Re
On Fri, 14 Dec 2012, Rob Godfrey wrote:
On 14 December 2012 01:02, Weston M. Price wrote:
On things such as bitmaps vs. enums, I think that's just a language
convention thing... I don't see a huge need to make such things
identical.
Naming is something that should be aligned between APIs
On Fri, 14 Dec 2012, Rafael Schloming wrote:
On Thu, Dec 13, 2012 at 5:37 PM, Justin wrote:
I've found the whole process of proposing API review dispiriting. You
can, of course, take it or leave it. I in no way wish to claim I have
better choices. I only wish to point out things that might
Comments below.
On Fri, 14 Dec 2012, Rafael Schloming wrote:
On Thu, Dec 13, 2012 at 5:37 PM, Justin wrote:
API usability is important and deserves attention.
Take, for instance, DeliveryState versus Disposition. That only serves to
confuse people. It's a difference that has no content.
[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti closed PROTON-136.
-
Resolution: Fixed
Fix Version/s: 0.3
Feature merged in from task branch kgiusti-proton-136:
http:
[
https://issues.apache.org/jira/browse/PROTON-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-181.
---
Resolution: Fixed
API modifications submitted as part of solution to PROTON-136
http://svn.apache.or
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 remi
22 matches
Mail list logo