On Fri, Mar 1, 2013 at 9:10 AM, Ken Giusti wrote:
> Thanks, I think you've clarified my understanding of the intended behavior
> of N in messenger::recv(N) - it places a limit to the number of messages
> the application can pn_messenger_get() for that invokation of recv(N). If
> N==-1, then the
Oops, meant to send this to the list.
-- Forwarded message --
From: Rafael Schloming
Date: Tue, Mar 5, 2013 at 6:44 PM
Subject: Re: put vs. send
To: Bozo Dragojevic
On Tue, Mar 5, 2013 at 3:25 PM, Bozo Dragojevic wrote:
> Wow, by not ever calling pn_messenger_send(), but only
On 3/5/13 8:52 PM, Rafael Schloming wrote:
On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross wrote:
On 03/05/2013 02:01 PM, Rafael Schloming wrote:
On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish
wrote:
So, am I understanding correctly? -- I should be able to get messages
from my sender to my re
On Tue, Mar 5, 2013 at 1:50 PM, Michael Goulish wrote:
>
>
> - Original Message -
> > On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming
> > wrote:
> > > On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu
> > > wrote:
> > >
> > >> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
> > >> >
>
On Tue, Mar 5, 2013 at 12:39 PM, Michael Goulish wrote:
>
>
> - Original Message -
> > On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross wrote:
> >
> > >
> > > On 03/05/2013 02:01 PM, Rafael Schloming wrote:
> > >
> > >> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish
> > >> > >> >wrote:
> > >>
- Original Message -
> On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming
> wrote:
> > On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu
> > wrote:
> >
> >> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
> >> >
> >> > On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
> >> >>
> >> >>
> >> >
On Tue, Mar 5, 2013 at 3:20 PM, Rafael Schloming wrote:
> On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu wrote:
>
>> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
>> >
>> > On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
>> >>
>> >>
>> >> This is a good explanation that we need to put in the
- Original Message -
> On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross wrote:
>
> >
> > On 03/05/2013 02:01 PM, Rafael Schloming wrote:
> >
> >> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish
> >> >> >wrote:
> >>
> >>
> >>> So, am I understanding correctly? -- I should be able to get
> >>>
On Tue, Mar 5, 2013 at 11:36 AM, Phil Harvey wrote:
> There's a confusing difference in the meanings of the delivery "is settled"
> methods in proton-j (Delivery.isSettled) and proton-c
> (pn_delivery_settled): their return values represent the local and remote
> values respectively. proton-j has
I would say you should document the semantics of the interface and leave
out irrelevant implementation behaviours, and that does often include
observable behaviours.
If we need to stay backwards compatible to all possible observable
behaviours then our implementation will be overly constrained and
On Tue, Mar 5, 2013 at 11:33 AM, Rajith Attapattu wrote:
> On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
> >
> > On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
> >>
> >>
> >> This is a good explanation that we need to put in the docs, as
> >> Application developers certainly need to know how i
On Tue, Mar 5, 2013 at 11:24 AM, Ted Ross wrote:
>
> On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
>
>>
>> This is a good explanation that we need to put in the docs, as
>> Application developers certainly need to know how it behaves.
>> If one were to use the current C impl, it certainly gives
On Tue, Mar 5, 2013 at 11:10 AM, Ted Ross wrote:
>
> On 03/05/2013 02:01 PM, Rafael Schloming wrote:
>
>> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish > >wrote:
>>
>>
>>> So, am I understanding correctly? -- I should be able to get messages
>>> from my sender to my receiver just by calling pu
Mick, great question!
As I mentioned in the other thread we owe it to application developers
to describe the behaviour.
And if we change the behaviour btw releases we need to document it
prominently in the release notes as is often the case applications
will be written taking advantage of certain b
If semantics like "put vs. send" are not stable as documented across
releases, then the API is not stable and people's applications will
break when they shouldn't. In other words, even documented changes in
semantics represent incompatible breaks in the API.
So, you should be documenting sema
There's a confusing difference in the meanings of the delivery "is settled"
methods in proton-j (Delivery.isSettled) and proton-c
(pn_delivery_settled): their return values represent the local and remote
values respectively. proton-j has a separate remotelySettled() method,
whereas proton-c appears
On Tue, Mar 5, 2013 at 2:24 PM, Ted Ross wrote:
>
> On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
>>
>>
>> This is a good explanation that we need to put in the docs, as
>> Application developers certainly need to know how it behaves.
>> If one were to use the current C impl, it certainly gives
Wow, I never thought I would have a philosophy question about documentation.
Should I be documenting semantics that will be stable across all[1] releases?
Or observable behavior in the release you, dear developer, have in your hands
right now?
Or, perhaps, both ?
I'll tell you, as a developer,
On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
This is a good explanation that we need to put in the docs, as
Application developers certainly need to know how it behaves.
If one were to use the current C impl, it certainly gives the
impression that put() is meant to write messages into your i
On Tue, Mar 5, 2013 at 2:01 PM, Rafael Schloming wrote:
> On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish wrote:
>
>>
>> quoth Rafi:
>>
>> > The semantics of pn_messenger_put allow it to send if it can do so
>> without
>> > blocking.
>>
>>
>> So, am I understanding correctly? -- I should be able
On 03/05/2013 02:01 PM, Rafael Schloming wrote:
On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish wrote:
So, am I understanding correctly? -- I should be able to get messages
from my sender to my receiver just by calling put() -- if the receiver
is ready to receive?
Not necessarily, the rece
+1
Rajith
On Tue, Mar 5, 2013 at 1:48 PM, Rafael Schloming wrote:
> I'm +1 on docs. It would be consistent with examples, tests, and tools.
>
> --Rafael
>
> On Tue, Mar 5, 2013 at 1:01 AM, Phil Harvey wrote:
>
>> I'm happy with the location although to increase consistency with other
>> projects
On Tue, Mar 5, 2013 at 10:42 AM, Michael Goulish wrote:
>
> quoth Rafi:
>
> > The semantics of pn_messenger_put allow it to send if it can do so
> without
> > blocking.
>
>
> So, am I understanding correctly? -- I should be able to get messages
> from my sender to my receiver just by calling put()
I'm +1 on docs. It would be consistent with examples, tests, and tools.
--Rafael
On Tue, Mar 5, 2013 at 1:01 AM, Phil Harvey wrote:
> I'm happy with the location although to increase consistency with other
> projects I have a mild preference for either "docs" or "doc". The former
> seems to be
[
https://issues.apache.org/jira/browse/PROTON-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593744#comment-13593744
]
Rafael H. Schloming commented on PROTON-261:
It means null/unset/pending. We c
quoth Rafi:
> The semantics of pn_messenger_put allow it to send if it can do so without
> blocking.
So, am I understanding correctly? -- I should be able to get messages
from my sender to my receiver just by calling put() -- if the receiver
is ready to receive?
The only transmission differe
[
https://issues.apache.org/jira/browse/PROTON-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593726#comment-13593726
]
Rafael H. Schloming commented on PROTON-259:
I wouldn't say it's a bug to crea
Keith Wall created PROTON-265:
-
Summary: Change Message#decode to signal inability to decode
entire buffer via exception rather than return value
Key: PROTON-265
URL: https://issues.apache.org/jira/browse/PROTON-265
Thanks! It worked.
- Original Message -
You should be able to assign JIRAs to yourself now
-- Rob
On 5 March 2013 16:50, Michael Goulish wrote:
> I created PROTON-260, but I can't seem to assign it to myself.
> Do I need some new permissions to do this?
>
[
https://issues.apache.org/jira/browse/PROTON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael goulish reassigned PROTON-260:
--
Assignee: michael goulish
> Messenger Documentation
> ---
>
>
[
https://issues.apache.org/jira/browse/PROTON-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-264:
--
Summary: Proton-J and Proton-C transports make inconsistent use of return
values within methods input a
Keith Wall created PROTON-264:
-
Summary: Proton-J and Proton-C transports make inconsistent use of
return values from methods input and output
Key: PROTON-264
URL: https://issues.apache.org/jira/browse/PROTON-264
[
https://issues.apache.org/jira/browse/PROTON-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned PROTON-263:
-
Assignee: Keith Wall
> JNIDelivery.isPartial should delegate to pn_delivery_partial
> ---
Keith Wall created PROTON-263:
-
Summary: JNIDelivery.isPartial should delegate to
pn_delivery_partial
Key: PROTON-263
URL: https://issues.apache.org/jira/browse/PROTON-263
Project: Qpid Proton
I
You should be able to assign JIRAs to yourself now
-- Rob
On 5 March 2013 16:50, Michael Goulish wrote:
> I created PROTON-260, but I can't seem to assign it to myself.
> Do I need some new permissions to do this?
>
I created PROTON-260, but I can't seem to assign it to myself.
Do I need some new permissions to do this?
[
https://issues.apache.org/jira/browse/PROTON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael goulish updated PROTON-260:
---
Description:
Write documentation for the Proton Messenger interface, to include:
introduc
[
https://issues.apache.org/jira/browse/PROTON-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reassigned PROTON-262:
--
Assignee: Keith Wall (was: Rob Godfrey)
> Fully implement (error) condtion API in Proton-J
[
https://issues.apache.org/jira/browse/PROTON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-225:
--
Description:
This issue is intended to cover the Transport API redesign proposed on the
mailing list
Rob Godfrey created PROTON-262:
--
Summary: Fully implement (error) condtion API in Proton-J
Key: PROTON-262
URL: https://issues.apache.org/jira/browse/PROTON-262
Project: Qpid Proton
Issue Type:
Keith Wall created PROTON-261:
-
Summary: pn_delivery_local_state and pn_delivery_remote_state can
return a zero value (outside that defined by the pn_disposition_t enum)
Key: PROTON-261
URL: https://issues.apache.org/
[
https://issues.apache.org/jira/browse/PROTON-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-261:
--
Description:
In proton-c, pn_delivery_local_state and pn_delivery_remote_state are defined
as returnin
On 2/25/13 9:44 PM, Rafael Schloming wrote:
The vote carries with 5 +1's and 0 -1's. I'll upload the artifacts shortly.
--Rafael
On Thu, Feb 21, 2013 at 1:54 PM, Rafael Schloming wrote:
Hi everyone, I've spun an RC3 with fixes for the two immediately soluble
issues that turned up with RC2. P
michael goulish created PROTON-260:
--
Summary: Messenger Documentation
Key: PROTON-260
URL: https://issues.apache.org/jira/browse/PROTON-260
Project: Qpid Proton
Issue Type: Improvement
On Tue, Mar 5, 2013 at 1:52 AM, Phil Harvey wrote:
> I've been working with the proton-j engine recently and want to clarify the
> threading model.
>
> The Proton web site [1] says Proton "is architected to be usable with any
> threading model as well as with non threaded applications".
>
> Turnin
Philip Harvey created PROTON-259:
Summary: proton-j engine operations do not check if the endpoint
is already closed
Key: PROTON-259
URL: https://issues.apache.org/jira/browse/PROTON-259
Project: Qpid
Phil and I are currently working on PROTON-256 - Improve Engine API Javadoc.
As part of this task, I'd like to start publishing the resulting
javadoc to qpid.apache.org and link from
http://qpid.apache.org/proton/documentation. My intention is to
automate this process using Apache Buildbot
http:/
I've been working with the proton-j engine recently and want to clarify the
threading model.
The Proton web site [1] says Proton "is architected to be usable with any
threading model as well as with non threaded applications".
Turning to the implementation, I've heard that the proton-j engine is
Keith Wall created PROTON-258:
-
Summary: Delivery interface should expose receiver settlement mode
Key: PROTON-258
URL: https://issues.apache.org/jira/browse/PROTON-258
Project: Qpid Proton
Issue
I'm happy with the location although to increase consistency with other
projects I have a mild preference for either "docs" or "doc". The former
seems to be the most common in other open source projects, and the latter
is the name used by Qpid.
Phil
On 4 March 2013 19:53, Michael Goulish wrote
50 matches
Mail list logo
