[
https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated PROTON-194:
-
Description:
The catalyst for this work was the need to conveniently build and test the JNI
bind
[
https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated PROTON-194:
-
Description:
The catalyst for this work was the need to conveniently build and test the JNI
bind
[
https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated PROTON-194:
-
Description:
The catalyst for this work was the need to conveniently build and test the JNI
bind
[
https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated PROTON-194:
-
Description:
The catalyst for this work was the need to conveniently build and test the JNI
bind
On 01/02/2013 07:14 PM, Ted Ross wrote:
I'd like to start a discussion on how, from an API perspective,
applications can use the request/response pattern. If we get this
right, we will remove a significant barrier to adoption of AMQP.
Middleware messaging systems typically do a poor job of supp
Gordon makes some good points. I'd like to add that I think historically a
big part of the hassle isn't actually necessarily solely the API but also
having to configure and manage the intermediary, and I think we need to
look there as well if we want to simplify the overall pattern.
It's also wort
[
https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Harvey updated PROTON-194:
-
Description:
The catalyst for this work was the need to conveniently build and test the JNI
bind
We are currently in the process of implementing the proton-jni binding
for the proton-c library that implements the Java Proton-API, allow
Java users to choose the C based proton stack if they wish. This work
is being performed on the jni-branch under PROTON-192 (for the JNI
work) and PROTON-194 (f
I believe that we have too many mailing lists and that we are missing
out on valuable collaboration and transparency as a result.
Too often in the past topics have been discussed on the dev list without
reflecting any of the discussion back to the user list, keeping a large
part of the communi
+1
I think this is a real problem and I would be supportive of
consolidating all of the discussion into one list. We either exclude
people by sending to one list or, like this email, we include all lists
and everybody gets three copies.
-Ted
On 01/18/2013 12:21 PM, Gordon Sim wrote:
I beli
On 01/18/2013 05:33 PM, Ted Ross wrote:
We either exclude people by sending to one list or, like this email, we
include all lists and everybody gets three copies.
Its not the duplicate copies that are the biggest issue with cross
posting in my view, its the tendency for the thread to get fragm
On Jan 18, 2013, at 12:51 PM, Gordon Sim wrote:
> On 01/18/2013 05:33 PM, Ted Ross wrote:
>> We either exclude people by sending to one list or, like this email, we
>> include all lists and everybody gets three copies.
>
> Its not the duplicate copies that are the biggest issue with cross posti
I'm in favor of combining them all into one.
If not that, then at least collapse the "proton" list. The level of traffic
on that list isn't unreasonable, and, frankly, keeping it separate probably
leads to some of the confusion we're seeing over the goals of this project.
-K
- Origina
I'd agree with Gordon.
1. We should keep the Message as a pure value object without any sort
of coupling to Messenger or other objects.
2. I'm in favor of layering features on top of a generic flexible core
component rather than putting them all in the same layer.
This allows us the freedom t
I agree that the qpid and proton users should be on the same list. Also, it's
useful for much of the development info to be open to the users list. My only
concern for a second list is for things that committers may need to talk about
but which the larger user community doesn't care about. For e
On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote:
>
> Any other thoughts on this? Does anyone have fears of being deluged
> with unwanted emails?
I think you're mostly right on this. In thinking about the split of
lists, a project like Qpid doesn't really have a separate of users and
dev
On Fri, Jan 18, 2013 at 02:19:01PM -0500, Darryl L. Pierce wrote:
> On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote:
> >
> > Any other thoughts on this? Does anyone have fears of being deluged
> > with unwanted emails?
>
> I think you're mostly right on this. In thinking about the split
On Jan 18, 2013, at 2:19 PM, Darryl L. Pierce wrote:
> On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote:
>>
>> Any other thoughts on this? Does anyone have fears of being deluged
>> with unwanted emails?
>
> I think you're mostly right on this. In thinking about the split of
> lists,
On Fri, Jan 18, 2013 at 11:17 AM, Keith W wrote:
> We are currently in the process of implementing the proton-jni binding
> for the proton-c library that implements the Java Proton-API, allow
> Java users to choose the C based proton stack if they wish. This work
> is being performed on the jni-b
> On Fri, Jan 18, 2013 at 2:29 PM, Rafael Schloming wrote:
>> The nub of the problem is the sharing of the Java Proton-API between
>> both proton-c and proton-j trees. Solutions based on svn-external and
>> a simple tree copy have been considered and discussed at length on
>> conference calls. We
I think you raise a good point about the goals of the project being
confused, but don't think the cause here is mailing lists. As we've seen,
recent threads have asked about "qpid vs proton", and to a lot of us this
is an odd thing to ask about because we think of proton as part of qpid.
However we
[
https://issues.apache.org/jira/browse/PROTON-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Pierce resolved PROTON-176.
-
Resolution: Fixed
> Provide a unit test framework for the Perl bindings
> ---
Hi Rafi,
You raise some good points, but I don't understand how keeping a separate
proton list makes it easier to provide a coherent view of the qpid project,
especially to newcomers.
As you point out:
> The project goals/identity issue
> in my
> mind has very little to do with the lists and m
On 01/18/2013 08:23 PM, Rafael Schloming wrote:
I think rearranging the lists is not a substitute for
rearranging the project and actively communicating about its structure.
I quite agree. My suggestion to consolidate discussions to one list is
not an attempt to imply anything about structure,
On 01/18/2013 06:55 PM, Steve Huston wrote:
I agree that the qpid and proton users should be on the same list.
Also, it's useful for much of the development info to be open to the
users list. My only concern for a second list is for things that
committers may need to talk about but which the larg
Sounds good to me.
> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Friday, January 18, 2013 5:12 PM
> To: us...@qpid.apache.org; proton@qpid.apache.org; d...@qpid.apache.org
> Subject: Re: mailing lists and fragmented communication
>
> On 01/18/2013 06:55 PM, Stev
26 matches
Mail list logo
