Re: Review Request 13683: Proton: provide accessor for drain state from link's peer.

2013-08-22 Thread Philip Harvey 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13683/#review25409
---



/proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/LinkImpl.java


Add @Override annotation. Not absolutely essential but worth doing if 
you're making other changes.


- Philip Harvey


On Aug. 20, 2013, 3 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13683/
> ---
> 
> (Updated Aug. 20, 2013, 3 p.m.)
> 
> 
> Review request for qpid, Philip Harvey, Rob Godfrey, and Rafael Schloming.
> 
> 
> Bugs: proton-375
> https://issues.apache.org/jira/browse/proton-375
> 
> 
> Repository: qpid
> 
> 
> Description
> ---
> 
> Adds an accessor to obtain the last know drain state received from the remote.
> 
> 
> Diffs
> -
> 
>   /proton/trunk/proton-c/bindings/python/proton.py 1514351 
>   /proton/trunk/proton-c/include/proton/engine.h 1514351 
>   /proton/trunk/proton-c/src/engine/engine-internal.h 1514351 
>   /proton/trunk/proton-c/src/engine/engine.c 1514351 
>   
> /proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Link.java
>  1514351 
>   /proton/trunk/proton-j/proton-api/src/main/resources/proton.py 1514351 
>   
> /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/LinkImpl.java
>  1514351 
>   
> /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/TransportReceiver.java
>  1514351 
>   
> /proton/trunk/proton-j/proton/src/main/java/org/apache/qpid/proton/engine/impl/TransportSender.java
>  1514351 
>   /proton/trunk/tests/python/proton_tests/engine.py 1514351 
> 
> Diff: https://reviews.apache.org/r/13683/diff/
> 
> 
> Testing
> ---
> 
> Unit test updated, passes for both proton-c and proton-j.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

[jira] [Created] (QPIDJMS-4) Add findbugs configuration

2013-08-22 Thread Philip Harvey (JIRA) 
Philip Harvey created QPIDJMS-4:
---

 Summary: Add findbugs configuration
 Key: QPIDJMS-4
 URL: https://issues.apache.org/jira/browse/QPIDJMS-4
 Project: Qpid JMS
  Issue Type: Improvement
Reporter: Philip Harvey
Assignee: Philip Harvey
Priority: Minor


This is being done as a quick way for us to keep track of code quality. We 
might remove this config if we set up integration with 
https://analysis.apache.org/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: UTF8 / binary strings in dynamic languages

2013-08-22 Thread Gordon Sim 

On 08/21/2013 10:43 PM, Justin Ross wrote:

On Wed, Aug 21, 2013 at 4:04 PM, Jimmy Jones  wrote:

I'm not convinced, but I'm prepared to be convinced. If I put a binary
value in a map and encoded it some of the time it might be valid utf8,
other times not. Could this lead to a class of subtle bugs where a receiver
written in a statically typed language will work most of the time when
the value appears as a vbin, but not other times when it "accidentally"
appears a a str16?


"If I put a binary value in a map and encoded it some of the time it
might be valid utf8, other times not."  This shouldn't be allowed to
happen, IMO.  You meant it to be a binary value--we have to find a way
to capture and preserve that information.


I believe the point was that for an application sending binary data via 
the ambiguous string type (between two processes in languages that have 
such a type), if that was encoded on the wire as str16 (i.e. utf8) it 
could lead to subtle bugs.


Testing could work until the actual binary payload was changed in some 
way such that it was not valid utf8.


By contrast, though more likely to be an issue, sending textual data via 
an ambiguous string in one language to another language that does not 
have the ambiguity will always produce the same (if slightly unexpected 
and mystifying) symptoms.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

a request regarding crossposting

2013-08-22 Thread Gordon Sim 
I believe that the dev list audience is a strict sub-set of the user 
list audience. Crossposting to both user and dev lists is therefore 
unnecessary and almost inevitably in any case leads to threads 
diverging. Where a thread evolves only on the dev list valuable 
information is missed on the user list and even in replies it becomes 
harder to reconcile the two again.


For that reason I'd request that you think very carefully before sending 
a mail to both user and dev lists. If you feel the user list will be 
interested (and I believe for most topics they will be), please consider 
only posting it there (perhaps with some introductory context if it 
relates to something that came up initially on the dev list).


Thanks (and sorry for being a pain)!

--Gordon

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: UTF8 / binary strings in dynamic languages

2013-08-22 Thread Andrew Stitcher 
On Wed, 2013-08-21 at 11:31 -0400, Justin Ross wrote:
> Jimmy, thanks for getting this started.  I'd love your feedback to
> help sort this out.
> 
> I think these are the cases:
> 
> 1. If the language string is unambiguously textual, send it as amqp str16
> 2. If the language string is unambiguously arbitrary bytes, send it as amqp 
> vbin
> 

I think the underlying problem is that there is no unambiguous text/bin
distinction for any given input for some of the (computer) languages.

Eg in the current C++ bindings both test strings and binary data are
equally represented by std:string. Now it is true that some of those
represent valid ASCII (no high bits sets) or utf8 encoding of unicode
codepoints. and can be losslessly transferred as such. However without
encoding the user semantic up front it is impossible to say distinguish
between a string starting "ABCD" and the binary representation of a
structure that starts with an integer 1145258561.

It seems from these discussions that Python and Perl (and probably other
languages) have idiomatic ways to deal with this distinction and we
should make those work.

Even in C++ there are some types that I think would better encode the
users intention: I would opine that std::string is more often used for
text and could be deemed utf8 encoded (C++03 has std::wstring to
indicate wide strings but with no defined encoding or character width;
in practice either utf16 or utf32 depending on implementation, C++11 is
better and has std::u16string and std::u32string which indicate utf16
and utf32 encoding respectively). To indicate binary data I'd say that
using std::vector would make most sense.

So I'd be in favour of changing the default for the C++ binding of
assuming std::string indicates utf8 data and make the user change the
encoding if it is not. I'd suggest also adding std::vector and
encoding that as binary. And adding the C++11 types too (in ifdefs).

Andrew



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: UTF8 / binary strings in dynamic languages

2013-08-22 Thread Justin Ross 
On Thu, Aug 22, 2013 at 8:41 AM, Gordon Sim  wrote:
> On 08/21/2013 10:43 PM, Justin Ross wrote:
>> "If I put a binary value in a map and encoded it some of the time it
>> might be valid utf8, other times not."  This shouldn't be allowed to
>> happen, IMO.  You meant it to be a binary value--we have to find a way
>> to capture and preserve that information.
>
> I believe the point was that for an application sending binary data via the
> ambiguous string type (between two processes in languages that have such a
> type), if that was encoded on the wire as str16 (i.e. utf8) it could lead to
> subtle bugs.
>
> Testing could work until the actual binary payload was changed in some way
> such that it was not valid utf8.

Right.  I'm saying that sucks, so don't do that.  For instance, we
could ask our users to use a 'Data' class to input arbitrary bytes,
and otherwise treat ambiguous strings as textual.

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Justin Ross 
On Thu, Aug 22, 2013 at 8:48 AM, Gordon Sim  wrote:
> I believe that the dev list audience is a strict sub-set of the user list
> audience.

I doubt this is the case.  I for one was a dev list subscriber for a
long time without having subscribed to user.

I agree about the trouble you're pointing out, of course!

Justin

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Gordon Sim 

On 08/22/2013 03:43 PM, Justin Ross wrote:

On Thu, Aug 22, 2013 at 8:48 AM, Gordon Sim  wrote:

I believe that the dev list audience is a strict sub-set of the user list
audience.


I doubt this is the case.  I for one was a dev list subscriber for a
long time without having subscribed to user.


Personally I would consider that rather bad form and would encourage 
anyone subscribed to dev to subscribe to users if that is not already 
the case.


Development detached from users is never a good thing. If you need to be 
on the dev list, you _need_ to be on the users list as well. Otherwise 
we force our users to be on the dev list just in case they miss something.


(Again, sorry for getting on my high horse here, but I feel quite 
strongly on this point).



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: UTF8 / binary strings in dynamic languages

2013-08-22 Thread Gordon Sim 

On 08/22/2013 03:36 PM, Justin Ross wrote:

On Thu, Aug 22, 2013 at 8:41 AM, Gordon Sim  wrote:

On 08/21/2013 10:43 PM, Justin Ross wrote:

"If I put a binary value in a map and encoded it some of the time it
might be valid utf8, other times not."  This shouldn't be allowed to
happen, IMO.  You meant it to be a binary value--we have to find a way
to capture and preserve that information.


I believe the point was that for an application sending binary data via the
ambiguous string type (between two processes in languages that have such a
type), if that was encoded on the wire as str16 (i.e. utf8) it could lead to
subtle bugs.

Testing could work until the actual binary payload was changed in some way
such that it was not valid utf8.


Right.  I'm saying that sucks, so don't do that.  For instance, we
could ask our users to use a 'Data' class to input arbitrary bytes,
and otherwise treat ambiguous strings as textual.


The point is that it is easy for people to miss that. Just as it is easy 
for them to miss the fact that you should choose the explicit utf8 type 
for textual data.


An explicit type is always preferable. The question is how to handle an 
ambiguous type. If encoded as a str16 then it may work in some case and 
fail in others; i.e. a subtle bug that testing may not catch depending 
on payloads actually tested. By contrast if it is encoded as a vbin the 
behaviour - even though admittedly unexpected for many - will at least 
be the same each time you try it independent of the actual contents of 
the string.



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Justin Ross 
I certainly agree with all of that, but it misses a category of
mailing list subscriber: at the time I was not a Qpid developer, but I
was interested in following Qpid development.

On Thu, Aug 22, 2013 at 10:49 AM, Gordon Sim  wrote:
> On 08/22/2013 03:43 PM, Justin Ross wrote:
>>
>> On Thu, Aug 22, 2013 at 8:48 AM, Gordon Sim  wrote:
>>>
>>> I believe that the dev list audience is a strict sub-set of the user list
>>> audience.
>>
>>
>> I doubt this is the case.  I for one was a dev list subscriber for a
>> long time without having subscribed to user.
>
>
> Personally I would consider that rather bad form and would encourage anyone
> subscribed to dev to subscribe to users if that is not already the case.
>
> Development detached from users is never a good thing. If you need to be on
> the dev list, you _need_ to be on the users list as well. Otherwise we force
> our users to be on the dev list just in case they miss something.
>
> (Again, sorry for getting on my high horse here, but I feel quite strongly
> on this point).
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Gordon Sim 

On 08/22/2013 04:00 PM, Justin Ross wrote:

I certainly agree with all of that, but it misses a category of
mailing list subscriber: at the time I was not a Qpid developer, but I
was interested in following Qpid development.


I don't think you can properly follow development without following the 
user list.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Justin Ross 
On Thu, Aug 22, 2013 at 11:10 AM, Gordon Sim  wrote:
> On 08/22/2013 04:00 PM, Justin Ross wrote:
>>
>> I certainly agree with all of that, but it misses a category of
>> mailing list subscriber: at the time I was not a Qpid developer, but I
>> was interested in following Qpid development.
>
> I don't think you can properly follow development without following the user
> list.

At various times in the past I've been a subscriber to the dev lists
at gnome and many other places without being subscribed to the user
list.  I don't think this is uncommon.

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: UTF8 / binary strings in dynamic languages

2013-08-22 Thread Justin Ross 
On Thu, Aug 22, 2013 at 10:54 AM, Gordon Sim  wrote:
>> Right.  I'm saying that sucks, so don't do that.  For instance, we
>> could ask our users to use a 'Data' class to input arbitrary bytes,
>> and otherwise treat ambiguous strings as textual.
>
> The point is that it is easy for people to miss that. Just as it is easy for
> them to miss the fact that you should choose the explicit utf8 type for
> textual data.
>
> An explicit type is always preferable. The question is how to handle an
> ambiguous type. If encoded as a str16 then it may work in some case and fail
> in others; i.e. a subtle bug that testing may not catch depending on
> payloads actually tested. By contrast if it is encoded as a vbin the
> behaviour - even though admittedly unexpected for many - will at least be
> the same each time you try it independent of the actual contents of the
> string.

Sorry, it took me too long to understand the scenario in question.
You and Jimmy are of course right about this very real gotcha.

Justin

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Darryl L. Pierce 
On Thu, Aug 22, 2013 at 04:10:03PM +0100, Gordon Sim wrote:
> On 08/22/2013 04:00 PM, Justin Ross wrote:
> >I certainly agree with all of that, but it misses a category of
> >mailing list subscriber: at the time I was not a Qpid developer, but I
> >was interested in following Qpid development.
> 
> I don't think you can properly follow development without following
> the user list.

+1 Justin may have been an exception to the case of subscribers.

-- 
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/



pgpFQOVxafzBb.pgp
Description: PGP signature

Re: a request regarding crossposting

2013-08-22 Thread Gordon Sim 

On 08/22/2013 04:35 PM, Justin Ross wrote:

On Thu, Aug 22, 2013 at 11:10 AM, Gordon Sim  wrote:

On 08/22/2013 04:00 PM, Justin Ross wrote:


I certainly agree with all of that, but it misses a category of
mailing list subscriber: at the time I was not a Qpid developer, but I
was interested in following Qpid development.


I don't think you can properly follow development without following the user
list.


At various times in the past I've been a subscriber to the dev lists
at gnome and many other places without being subscribed to the user
list.  I don't think this is uncommon.


Stepping back, the key point I want to make is that for the Qpid 
community, I think it is important that most conversations happen on the 
user list to keep our user informed and to solicit their input.


Therefore for anyone on the Qpid dev list that is not on the user list, 
I would strongly encourage you to subscribe to the user list also. 
Otherwise you will miss out in useful(!) information as I for one will 
post there by default.


To the point of this thread, crossposting to both lists is in my view 
simply a way for information again to miss the user list when a thread 
diverges. Doing so in my view sacrifices the very real needs of lots of 
users who are not on the dev list for the preferences of a possibly 
hypothetical group that are on dev list but not user list.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: a request regarding crossposting

2013-08-22 Thread Fraser Adams 

FWIW I totally agree with Gordon here.

If you subscribe so the thinking of Gregorio Robles paper

http://www.opensourcejahrbuch.de/download/jb2004/chapter_03/III-3-Robles.pdf

among other things he says:

"
Users should be treated as co-developers

   The users are treated like co-developers and so they should have
   access to the source code of the software. Furthermore users are
   encouraged to submit additions to the software, code fixes for the
   software, bug reports, documentation etc. Having more co-developers
   increases the rate at which the software evolves. Linus's law
    states, "Given enough
   eyeballs all bugs are shallow." This means that if many users view
   the source code, they will eventually find all bugs and suggest how
   to fix them. Note that some users have advanced programming skills,
   and furthermore, each user's machine provides an additional testing
   environment. This new testing environment offers that ability to
   find and fix a new bug.

"
Not trying to be critical of Justin or anyone else here, just wanting to 
voice my support for Gordon.


I for one rather like the philosophical/cultural aspects brought out in 
that paper - it's worth a read.


Regards,
Frase



On 22/08/13 15:49, Gordon Sim wrote:

On 08/22/2013 03:43 PM, Justin Ross wrote:

On Thu, Aug 22, 2013 at 8:48 AM, Gordon Sim  wrote:
I believe that the dev list audience is a strict sub-set of the user 
list

audience.


I doubt this is the case.  I for one was a dev list subscriber for a
long time without having subscribed to user.


Personally I would consider that rather bad form and would encourage 
anyone subscribed to dev to subscribe to users if that is not already 
the case.


Development detached from users is never a good thing. If you need to 
be on the dev list, you _need_ to be on the users list as well. 
Otherwise we force our users to be on the dev list just in case they 
miss something.


(Again, sorry for getting on my high horse here, but I feel quite 
strongly on this point).



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5079) Only export necessary symbols from the supported client API libraries

2013-08-22 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747796#comment-13747796
 ] 

ASF subversion and git services commented on QPID-5079:
---

Commit 1516549 from [~astitcher] in branch 'qpid/trunk'
[ https://svn.apache.org/r1516549 ]

QPID-5079: Get library import/export declarations working for linux
- Only qpidmessaging and qpidtypes libraries are affected

> Only export necessary symbols from the supported client API libraries
> -
>
> Key: QPID-5079
> URL: https://issues.apache.org/jira/browse/QPID-5079
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
> Environment: Linux
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5079) Only export necessary symbols from the supported client API libraries

2013-08-22 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747797#comment-13747797
 ] 

ASF subversion and git services commented on QPID-5079:
---

Commit 1516550 from [~astitcher] in branch 'qpid/trunk'
[ https://svn.apache.org/r1516550 ]

QPID-5079: Added link map file to cut the number of symbols exported even 
further
- It seems that the library import/export mechanism isn't sufficient under the
  gnu tool chain to really limit the exported symbols

> Only export necessary symbols from the supported client API libraries
> -
>
> Key: QPID-5079
> URL: https://issues.apache.org/jira/browse/QPID-5079
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
> Environment: Linux
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5079) Only export necessary symbols from the supported client API libraries

2013-08-22 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747799#comment-13747799
 ] 

ASF subversion and git services commented on QPID-5079:
---

Commit 1516552 from [~astitcher] in branch 'qpid/trunk'
[ https://svn.apache.org/r1516552 ]

QPID-5079: Add script to compare symbols exported by library with expected list

> Only export necessary symbols from the supported client API libraries
> -
>
> Key: QPID-5079
> URL: https://issues.apache.org/jira/browse/QPID-5079
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
> Environment: Linux
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5079) Only export necessary symbols from the supported client API libraries

2013-08-22 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747798#comment-13747798
 ] 

ASF subversion and git services commented on QPID-5079:
---

Commit 1516551 from [~astitcher] in branch 'qpid/trunk'
[ https://svn.apache.org/r1516551 ]

QPID-5079: Remove unused and unecessary member of MessagingException class
- Potentially an ABI change but noone can really have used this for anything.

> Only export necessary symbols from the supported client API libraries
> -
>
> Key: QPID-5079
> URL: https://issues.apache.org/jira/browse/QPID-5079
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
> Environment: Linux
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org