Re: A case in favor of separate repos for language bindings

2015-08-19 Thread Ken Giusti
While I'm in favor of breaking out the bindings (actually, I'd like to see 
wider changes to the overall structure of proton, specifically proton-c.  But I 
won't thread-jack - I'll start a separate thread).

However - I think the python binding is the one binding where it may not be 
practical, sadly.

See inline:

- Original Message -
 From: Flavio Percoco fla...@redhat.com
 To: proton@qpid.apache.org
 Sent: Wednesday, August 19, 2015 8:05:10 AM
 Subject: Re: A case in favor of separate repos for language bindings
 
 On 19/08/15 12:34 +0100, Robbie Gemmell wrote:
 I can see certain benefits to such a separation, mainly for folks
 interested only in the bindings, but if I'm honest I'm not sure those
 outweigh the additional complication it seems it may bring in some of
 the other areas.
 
 I think they actually do but probably because I don't see any
 complications being added to proton-c itself but rather a
 simplification of the current structure. It'll bring a more intuitive
 structure to the project rather than having the bindings under
 `proton-c`, which is very confusing :)
 
 The python bindings are slightly more interesting than the others due
 to being at the heart of the python based tests that exist for
 proton-c and proton-j, so splitting them out actually creates a bit of
 a circular dependency with proton / its tests (especially when having
 the submodules in both repos). You mentioned thinking we wouldn't need
 to track the binding within the proton tree (but could do so to
 prevent a breaking change for existing things), and instead use an
 installed version of the bindings. In practice I guess it would be
 about the same in terms of updating proton-c and the bindings and the
 related python-based tests at the same time (adding an install, or
 possibly two, in the middle).
 
 It won't be the same. The reason is that we're currently ensuring that
 proton-c doesn't break the bindings 'master' version. This is being
 done on the assumption that bindings will be released along with
 proton-c and there'll be a binding release per every proton-c minor.
 
 The above is not an ideal scenarion in my opinion. Ideally, we'd have
 a release of the bindings that will be able to track several minor
 releases of proton-c, but this will probably come later once proton-c
 stabilizes a bit more. However, I believe the current structure allows
 for breaking changes to land because it tests things against master
 only rather than making sure older, still maintained, versions are not
 being broken.
 
 Going back to the proposal, I think the circular dependency is not
 really necessary and we could just have the python bindings being
 installed. The installed version can either be the current master
 branch (pip knows how to install from git) or the latest stable
 version. Furthermore, we could even have a list of versions that we
 want to test against.
 


I don't see how this would work in the case of proton-c (or proton-j) API 
changes.   Robbie raises that point, and I don't see how this would work in 
practice with the bindings being out-of-tree (and the unit tests being 
implemented in python).

Specifically:
Proton-c adds a new API.  That new API cannot be tested using the python unit 
tests until the python binding is updated.  So the dev would have to also 
update the python binding and juggle the two in order to complete testing.

One way to address this: stop developing unit tests in python.  Instead, going 
forward all new proton-c tests should be done in C and put in the existing 
proton-c/tests dir.   See my next point:


 To expand the above issue a bit more, I think it's wrong to have the
 python tests as part of the in-tree tests for proton-c. 


I agree with this point, though I suspect we won't do it due to inertia alone.

I think each binding and language implementation (Java/C) should have their own 
in tree unit tests written in the implementation language.  Each binding should 
have just enough tests to test the binding itself - not the underlying C code.  
The C code should have its own unit tests, written in C.

Doing the above would simplify and, in the case of python, speed up the unit 
test runs.  Currently, the python unit tests may be repeated several times: 
once under cmake, and, if tox is installed, once for each version of python 
available on the system.  That can be fixed by configuring tox to just run a 
subset of the unit tests, but since the unit tests are written to exercise more 
than just the python interface we'd have to be careful selecting the proper 
subset for python.

But... well.. inertia.


 Ideally, this
 should be the work of a CI system responsible for doing integration
 tests. Not saying we should solve this issue now but the proposed
 structure allows for it to happen.
 

Nope.  There has to be an in-tree set of unit tests that devs run (and pass) 
before any modifications are pushed.  Full stop.  

Good or bad, this project doesn't have the CI 

Re: A case in favor of separate repos for language bindings

2015-08-19 Thread Robbie Gemmell
I can see certain benefits to such a separation, mainly for folks
interested only in the bindings, but if I'm honest I'm not sure those
outweigh the additional complication it seems it may bring in some of
the other areas.

The python bindings are slightly more interesting than the others due
to being at the heart of the python based tests that exist for
proton-c and proton-j, so splitting them out actually creates a bit of
a circular dependency with proton / its tests (especially when having
the submodules in both repos). You mentioned thinking we wouldn't need
to track the binding within the proton tree (but could do so to
prevent a breaking change for existing things), and instead use an
installed version of the bindings. In practice I guess it would be
about the same in terms of updating proton-c and the bindings and the
related python-based tests at the same time (adding an install, or
possibly two, in the middle). Releasing (in terms of source, here at
Apache) seems like it would become more 'interesting' though, with
potential again for the bindings needing proton-c (+proton-j) updates,
but proton-c (+proton-j) needing the bindings updates for updated
tests. I guess that might point to splitting the python tests out on
their own as well so it depended on both separately.

Perhaps I'm overthinking this though; how would you see some of those
things working?

I also can't say that I'd be a particular fan of using submodules,
most of the things I've read about or tried with them have been a
turnoff...but I'm mostly skipping over that for now.

Robbie

On 18 August 2015 at 08:17, Flavio Percoco fla...@redhat.com wrote:
 Greetings,

 I'd like to take a chance, now that 0.10 is out, to make a point in
 favor of using submodules rather than having all bindings in the same
 repository.

 I think qpid-proton has reached the point where it's mature enough to
 have some of the bindings promoted to having their own repos. More
 importantly, I believe these bindings are mature enough and ready to
 build a community on their own.

 Lets take the python bindings, for instance. I've been contributing to
 the python bindings quite a bit in the last couple of months. The
 bindings went from depending on cmake for tests to having their own,
 still dependant on proton-test, test suite that is self-maintained.

 Furthermore, the python bindings went from depending on cmake to be
 built to being self-built using python's internal build system. It's
 still possible - and in fact, it still happens - to build these
 drivers running cmake, although it's, in my personal opinion, not
 recommended.

 As you can see from the above, the python bindings depend on proton-c
 but they don't need to live in the same codebase. Therefore, I've
 prepared a small POC to show case this repo structure:

 - https://github.com/FlaPer87/test-python-qpid-proton

 The above repo contains the python-qpid-proton code. As you can tell
 from the commit history, not many changes were required to set it up.
 The relevant bits of this repo, I believe, are the ones related to the
 submodule. The qpid-proton submodule points qpid-proton's master
 branch in the test-python-qpid-proton branch, whereas in the 0.10
 branch, it tracks qpid-proton's 0.10.x. This is important for the
 bindings to keep track of the right code/release/tests.

 - https://github.com/FlaPer87/qpid-proton/tree/submodules

 The above is a fork of the qpid-proton repo we use already but rather
 than having the python-qpid-bindings in tree, it just tracks the
 master branch. (I created a `submodules` branch because I didn't want
 to mess with the master branch in my fork).

 I don't think tracking the binding in the qpid-proton repo is
 necessary but I see how it's useful to avoid introducing breaking
 changes on drivers. To be more precise, I don't think the above is
 necessary because if we are testing bindings in cmake to make sure we
 don't break backwards compatibility, we could simply install the
 latest stable version and test against that, rather than testing
 against the latest binding's master, which could, but shouldn't, be
 broken.

 I wouldn't probably advocate for the above to applied to every binding
 we have since some of them might not be ready for this but I
 definitely want to advocate to make this happen for the python binding
 (and other bindings).

 This structure will make it easier to mainting bindings, to build a
 community around these bindings - I contribute more to the python
 binding than proton-c. It'll also help keeping a clean history for
 each project and to issue binding releases, therefore creating
 tags for bindings, as needed.

 I get it's worked well so far and probably some of you won't be happy
 with this proposal but, git is powerful enough to support the above
 structure, which is ideal for these kind of projects. Correct me if
 I'm wrong but I believe the current structure also comes from the old
 times when qpid-proton used to be in 

Re: A case in favor of separate repos for language bindings

2015-08-19 Thread Flavio Percoco

On 19/08/15 12:34 +0100, Robbie Gemmell wrote:

I can see certain benefits to such a separation, mainly for folks
interested only in the bindings, but if I'm honest I'm not sure those
outweigh the additional complication it seems it may bring in some of
the other areas.


I think they actually do but probably because I don't see any
complications being added to proton-c itself but rather a
simplification of the current structure. It'll bring a more intuitive
structure to the project rather than having the bindings under
`proton-c`, which is very confusing :)


The python bindings are slightly more interesting than the others due
to being at the heart of the python based tests that exist for
proton-c and proton-j, so splitting them out actually creates a bit of
a circular dependency with proton / its tests (especially when having
the submodules in both repos). You mentioned thinking we wouldn't need
to track the binding within the proton tree (but could do so to
prevent a breaking change for existing things), and instead use an
installed version of the bindings. In practice I guess it would be
about the same in terms of updating proton-c and the bindings and the
related python-based tests at the same time (adding an install, or
possibly two, in the middle).


It won't be the same. The reason is that we're currently ensuring that
proton-c doesn't break the bindings 'master' version. This is being
done on the assumption that bindings will be released along with
proton-c and there'll be a binding release per every proton-c minor.

The above is not an ideal scenarion in my opinion. Ideally, we'd have
a release of the bindings that will be able to track several minor
releases of proton-c, but this will probably come later once proton-c
stabilizes a bit more. However, I believe the current structure allows
for breaking changes to land because it tests things against master
only rather than making sure older, still maintained, versions are not
being broken.

Going back to the proposal, I think the circular dependency is not
really necessary and we could just have the python bindings being
installed. The installed version can either be the current master
branch (pip knows how to install from git) or the latest stable
version. Furthermore, we could even have a list of versions that we
want to test against.

To expand the above issue a bit more, I think it's wrong to have the
python tests as part of the in-tree tests for proton-c. Ideally, this
should be the work of a CI system responsible for doing integration
tests. Not saying we should solve this issue now but the proposed
structure allows for it to happen.


Releasing (in terms of source, here at
Apache) seems like it would become more 'interesting' though, with
potential again for the bindings needing proton-c (+proton-j) updates,
but proton-c (+proton-j) needing the bindings updates for updated
tests. I guess that might point to splitting the python tests out on
their own as well so it depended on both separately.


What python tests are you referring to? The ones under `tests/python`
?

Those are the only ones I know of and those are still in the
`proton-c` repo. The python bindings access those through the
submodule for now but yes, I'd agree that eventually, those tests
could even be on their own.


Perhaps I'm overthinking this though; how would you see some of those
things working?


Totally honest? I think Java should have its own tests and let python
alone. Maintaining python2.5 - because that's what the tests support -
plus all the self-written tests libraries and whatnot is a burden that
I think we should not carry. Most of the things being maintained under
the `tests/python` 'package' exists already in the python community
and are widely used and tests. I know it seems easier to maintain 1 test
suite for 2 bindings rather than 2 but it really isn't. Not in this
case, at the very least.

However, based on the current situation, I'd either have the test code
on its own or simply follow the proposed structure and have the
bindings following proton-c and consuming tests from there.


I also can't say that I'd be a particular fan of using submodules,
most of the things I've read about or tried with them have been a
turnoff...but I'm mostly skipping over that for now.


In my experience, if done right, they work and they're not hard to
update/maintain. Circular dependencies are to avoid, agreed. One case
where I've had good experience with submodules is the rustlang. I
guess giving this a try would tell better.

Thanks for your reply,
Flavio



Robbie

On 18 August 2015 at 08:17, Flavio Percoco fla...@redhat.com wrote:

Greetings,

I'd like to take a chance, now that 0.10 is out, to make a point in
favor of using submodules rather than having all bindings in the same
repository.

I think qpid-proton has reached the point where it's mature enough to
have some of the bindings promoted to having their own repos. More
importantly, I believe these bindings are 

Re: [ANNOUNCE] Apache Qpid Proton 0.10 released

2015-08-19 Thread Robbie Gemmell
Yes, its tagged as 0.10.

You may need to fetch the tags explicitly to see it: git fetch --tags

Robbie

On 19 August 2015 at 17:04, Irina Boverman ibove...@redhat.com wrote:
 Hi Robbie,
 Is there a tag/branch for proton java 0.10 released?
 Regards, Irina.
 - Original Message -
 From: Robbie Gemmell rob...@apache.org
 To: us...@qpid.apache.org, proton@qpid.apache.org
 Sent: Saturday, August 15, 2015 2:14:07 PM
 Subject: [ANNOUNCE] Apache Qpid Proton 0.10 released

 The Apache Qpid community is pleased to announce the immediate
 availability of Apache Qpid Proton 0.10.

 Qpid Proton is an AMQP 1.0 messaging library. It can be used in a wide
 range of messaging applications including brokers, clients, routers,
 bridges, proxies, and more.

 This release incorporates a number of defect fixes and enhancements,
 including Python 3 support for for the Python bidings and a new SASL
 API and optional cyrus-sasl integration for Proton-C. Release notes
 are available at:
 http://qpid.apache.org/releases/qpid-proton-0.10/release-notes.html

 The release is available now from our website:
 http://qpid.apache.org/download.html

 Proton-J is also available via Maven Central:
 http://qpid.apache.org/maven.html

 Thanks to all involved.

 Robbie


proton-j tests failing on master?

2015-08-19 Thread Gordon Sim
The proton-j tests appear to be failing on master for me, even for a 
completely clean build with all the stuff that proton-j generates in the 
source tree removed as well:



Leaked an instance of 'sun.nio.ch.ServerSocketChannelImpl[/127.0.0.1:36861]' 
from:
java.lang.Exception
at 
org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.serverSocketChannel(LeakTestReactor.java:64)
at 
org.apache.qpid.proton.reactor.impl.AcceptorImpl.init(AcceptorImpl.java:89)
at 
org.apache.qpid.proton.reactor.impl.ReactorImpl.acceptor(ReactorImpl.java:429)
at 
org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:235)




Tests run: 49, Failures: 11, Errors: 22, Skipped: 0, Time elapsed: 0.198 sec 
 FAILURE!
connect[0](org.apache.qpid.proton.reactor.ReactorTest)  Time elapsed: 0.008 sec  
 ERROR!
java.lang.NoSuchMethodError: 
org.apache.qpid.proton.engine.impl.CollectorImpl.put(Lorg/apache/qpid/proton/engine/Event$Type;Ljava/lang/Object;)Lorg/apache/qpid/proton/engine/impl/EventImpl;
at 
org.apache.qpid.proton.engine.impl.ConnectionImpl.put(ConnectionImpl.java:644)
at 
org.apache.qpid.proton.engine.impl.ConnectionImpl.collect(ConnectionImpl.java:626)
at 
org.apache.qpid.proton.reactor.impl.ReactorImpl.connection(ReactorImpl.java:416)
at 
org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:258)




barfOnLink[1](org.apache.qpid.proton.reactor.ReactorTest)  Time elapsed: 0.008 sec  
 FAILURE!
junit.framework.AssertionFailedError: Resources leaked
at 
org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.assertNoLeaks(LeakTestReactor.java:101)
at 
org.apache.qpid.proton.reactor.impl.LeakTestReactor.assertNoLeaks(LeakTestReactor.java:115)
at 
org.apache.qpid.proton.reactor.ReactorTest.checkForLeaks(ReactorTest.java:96)
at 
org.apache.qpid.proton.reactor.ReactorTest.after(ReactorTest.java:102)


plus many, many more similar to these. Anyone else seeing this?


Re: [ANNOUNCE] Apache Qpid Proton 0.10 released

2015-08-19 Thread Irina Boverman
Hi Robbie,
Is there a tag/branch for proton java 0.10 released?
Regards, Irina.
- Original Message -
From: Robbie Gemmell rob...@apache.org
To: us...@qpid.apache.org, proton@qpid.apache.org
Sent: Saturday, August 15, 2015 2:14:07 PM
Subject: [ANNOUNCE] Apache Qpid Proton 0.10 released

The Apache Qpid community is pleased to announce the immediate
availability of Apache Qpid Proton 0.10.

Qpid Proton is an AMQP 1.0 messaging library. It can be used in a wide
range of messaging applications including brokers, clients, routers,
bridges, proxies, and more.

This release incorporates a number of defect fixes and enhancements,
including Python 3 support for for the Python bidings and a new SASL
API and optional cyrus-sasl integration for Proton-C. Release notes
are available at:
http://qpid.apache.org/releases/qpid-proton-0.10/release-notes.html

The release is available now from our website:
http://qpid.apache.org/download.html

Proton-J is also available via Maven Central:
http://qpid.apache.org/maven.html

Thanks to all involved.

Robbie


Re: proton-j tests failing on master?

2015-08-19 Thread Robbie Gemmell
Seems to be working here, and passed in CI on all the runs from
commits yesterday:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/

NoSuchMethodError is an interesting one. I think code in that area
will have changed with Bozo's recent commit, but the only likely way
that should cause issues is if something stale is in the loop,
otherwise I'd expect compilation issues. I tend only to see
NoSuchMethodError when running Eclipse and MAven (CLI) builds in the
same tree at the same time and they can trip each other up. Other than
that, not really.

Robbie

On 19 August 2015 at 16:54, Gordon Sim g...@redhat.com wrote:
 The proton-j tests appear to be failing on master for me, even for a
 completely clean build with all the stuff that proton-j generates in the
 source tree removed as well:

 Leaked an instance of
 'sun.nio.ch.ServerSocketChannelImpl[/127.0.0.1:36861]' from:
 java.lang.Exception
 at
 org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.serverSocketChannel(LeakTestReactor.java:64)
 at
 org.apache.qpid.proton.reactor.impl.AcceptorImpl.init(AcceptorImpl.java:89)
 at
 org.apache.qpid.proton.reactor.impl.ReactorImpl.acceptor(ReactorImpl.java:429)
 at
 org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:235)



 Tests run: 49, Failures: 11, Errors: 22, Skipped: 0, Time elapsed: 0.198
 sec  FAILURE!
 connect[0](org.apache.qpid.proton.reactor.ReactorTest)  Time elapsed:
 0.008 sec   ERROR!
 java.lang.NoSuchMethodError:
 org.apache.qpid.proton.engine.impl.CollectorImpl.put(Lorg/apache/qpid/proton/engine/Event$Type;Ljava/lang/Object;)Lorg/apache/qpid/proton/engine/impl/EventImpl;
 at
 org.apache.qpid.proton.engine.impl.ConnectionImpl.put(ConnectionImpl.java:644)
 at
 org.apache.qpid.proton.engine.impl.ConnectionImpl.collect(ConnectionImpl.java:626)
 at
 org.apache.qpid.proton.reactor.impl.ReactorImpl.connection(ReactorImpl.java:416)
 at
 org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:258)



 barfOnLink[1](org.apache.qpid.proton.reactor.ReactorTest)  Time elapsed:
 0.008 sec   FAILURE!
 junit.framework.AssertionFailedError: Resources leaked
 at
 org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.assertNoLeaks(LeakTestReactor.java:101)
 at
 org.apache.qpid.proton.reactor.impl.LeakTestReactor.assertNoLeaks(LeakTestReactor.java:115)
 at
 org.apache.qpid.proton.reactor.ReactorTest.checkForLeaks(ReactorTest.java:96)
 at
 org.apache.qpid.proton.reactor.ReactorTest.after(ReactorTest.java:102)


 plus many, many more similar to these. Anyone else seeing this?


Re: A case in favor of separate repos for language bindings

2015-08-19 Thread Robbie Gemmell
On 19 August 2015 at 13:05, Flavio Percoco fla...@redhat.com wrote:
 On 19/08/15 12:34 +0100, Robbie Gemmell wrote:

 I can see certain benefits to such a separation, mainly for folks
 interested only in the bindings, but if I'm honest I'm not sure those
 outweigh the additional complication it seems it may bring in some of
 the other areas.


 I think they actually do but probably because I don't see any
 complications being added to proton-c itself but rather a
 simplification of the current structure.

Ken has covered much of what I was thinking about.

  It'll bring a more intuitive
 structure to the project rather than having the bindings under
 `proton-c`, which is very confusing :)


I can see having them elsewhere might be more intuitive, especially
for folks who dont know or care that they are using proton-c under the
covers while using them.

I guess if they were kept in-tree they could be moved at to the top
level to make them more obvious but then presumably the same might
need done for the others, and that still wouldn't make a difference to
the various other points in your suggestion.

 The python bindings are slightly more interesting than the others due
 to being at the heart of the python based tests that exist for
 proton-c and proton-j, so splitting them out actually creates a bit of
 a circular dependency with proton / its tests (especially when having
 the submodules in both repos). You mentioned thinking we wouldn't need
 to track the binding within the proton tree (but could do so to
 prevent a breaking change for existing things), and instead use an
 installed version of the bindings. In practice I guess it would be
 about the same in terms of updating proton-c and the bindings and the
 related python-based tests at the same time (adding an install, or
 possibly two, in the middle).


 It won't be the same.

I just meant in terms of which files people would need to update it
would be similar, but with some install steps added (depending on what
you change), not any effect on what is or isnt being tested.

The reason is that we're currently ensuring that
 proton-c doesn't break the bindings 'master' version. This is being
 done on the assumption that bindings will be released along with
 proton-c and there'll be a binding release per every proton-c minor.

 The above is not an ideal scenarion in my opinion. Ideally, we'd have
 a release of the bindings that will be able to track several minor
 releases of proton-c, but this will probably come later once proton-c
 stabilizes a bit more. However, I believe the current structure allows
 for breaking changes to land because it tests things against master
 only rather than making sure older, still maintained, versions are not
 being broken.

 Going back to the proposal, I think the circular dependency is not
 really necessary and we could just have the python bindings being
 installed. The installed version can either be the current master
 branch (pip knows how to install from git) or the latest stable
 version. Furthermore, we could even have a list of versions that we
 want to test against.

 To expand the above issue a bit more, I think it's wrong to have the
 python tests as part of the in-tree tests for proton-c. Ideally, this
 should be the work of a CI system responsible for doing integration
 tests. Not saying we should solve this issue now but the proposed
 structure allows for it to happen.

 Releasing (in terms of source, here at
 Apache) seems like it would become more 'interesting' though, with
 potential again for the bindings needing proton-c (+proton-j) updates,
 but proton-c (+proton-j) needing the bindings updates for updated
 tests. I guess that might point to splitting the python tests out on
 their own as well so it depended on both separately.


 What python tests are you referring to? The ones under `tests/python`
 ?

 Those are the only ones I know of and those are still in the
 `proton-c` repo.

Those are the ones. As Ken has largely covered, its important to note
that those exist mostly (entirely?) to test proton-c and proton-j
rather than the python bindings themselves (though given how they
work, they kinda do that implicitly too). Their need of the python
bindings (and in turn proton again) to work however would present
challenges as Ken mentioned.

 The python bindings access those through the
 submodule for now but yes, I'd agree that eventually, those tests
 could even be on their own.

 Perhaps I'm overthinking this though; how would you see some of those
 things working?


 Totally honest? I think Java should have its own tests and let python
 alone. Maintaining python2.5 - because that's what the tests support -
 plus all the self-written tests libraries and whatnot is a burden that
 I think we should not carry. Most of the things being maintained under
 the `tests/python` 'package' exists already in the python community
 and are widely used and tests. I know it seems easier to maintain 1 test
 suite 

[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported

2015-08-19 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14703570#comment-14703570
 ] 

ASF subversion and git services commented on PROTON-950:


Commit 14956b07edc3de93f67179c753bbedcd9eba51a6 in qpid-proton's branch 
refs/heads/master from [~gsim]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=14956b0 ]

PROTON-950: don't force sasl layer by default


 SASL PLAIN over cleartext should be supported
 -

 Key: PROTON-950
 URL: https://issues.apache.org/jira/browse/PROTON-950
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.10
Reporter: Ted Ross
Assignee: Andrew Stitcher
Priority: Blocker
 Fix For: 0.10


 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if 
 the connection is encrypted (using SSL).  This is a surprising change of 
 behavior from earlier versions of Proton and it's arguable that a security 
 policy like that should be left to the application using the Proton library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: All about proton memory management (or C++, python and Go - Oh My!)

2015-08-19 Thread aconway
On Wed, 2015-08-19 at 10:45 -0400, Ken Giusti wrote:
 Nicely done Alan! 
 
 One point - I'm a little confused about your advice regarding 
 pn_object_decref: 
 
  The proton C API has standard reference counting rules (but see [1] 
  below)
 
  * A pointer returned by a pn_ function is either borrowed by the 
  caller, or
  the caller owns a reference (the API doc says which.)
  * The owner of a reference must call pn_object_decref() exactly 
  once to
  release it.
 
 Really?  What about those proton objects that have a pn_X_free() 
 method?  I believe the corresponding pn_X() allocation methods pass 
 back an owning reference to the object.  If a pn_X_free() exists (and 
 the user never calls pn_object_incref() on the object), shouldn't the 
 user use the pn_X_free() method instead?
 
 Maybe the doc should make that distinction, e.g.:
 
 * if an object of type pn_X_t has a corresponding pn_X_free() method, 
 call the pn_X_free() method to release your reference to the object.
 * otherwise, if you have called pn_object_incref() on the object, you 
 must call pn_object_decref() on the object to release your reference.

From skimming the source, I believe pn_x_free looks at the refcount
itself and behaves like pn_object_decref without the

if (--refcount=0) pn_x_free(me) 

So in theory they *should* work together. The proton lib has no way of
knowing whether the last thing to release an object will be an internal
decref or a pn_x_free from the user, so I sure *hope* they work
together.

However I did want to make the point that you should EITHER use
refcounts only OR free only, not both. Even if it works today your code
or your head may explode later. IMO normal C code (including bindings
to languages without finalizers like Go) should use free only, bindings
to automated memory languages like python and soon C++ should use
refcounts only.

Of course the difference between theory and practice is that in theory 
they are the same and in practice they are different.




[jira] [Commented] (PROTON-865) C++ reactor client binding

2015-08-19 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14703797#comment-14703797
 ] 

ASF subversion and git services commented on PROTON-865:


Commit c69625830951abca7c68b128dd4db1439effee65 in qpid-proton's branch 
refs/heads/cjansen-cpp-client from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c696258 ]

PROTON-865: Add some explanation of source and target to the overview doc.


 C++ reactor client binding
 --

 Key: PROTON-865
 URL: https://issues.apache.org/jira/browse/PROTON-865
 Project: Qpid Proton
  Issue Type: New Feature
 Environment: C++
Reporter: Cliff Jansen
Assignee: Cliff Jansen

 This JIRA tracks initial work on a C++ binding to the Proton reactor event 
 based model with an eye to providing an API very similar to the python 
 client.  As stated on the Proton list, the broad goals are:
   to make it easy to write simple programs
   natural to build out more complicated ones
   very similar API to the Python client
   lean and performant
 The initial introduction with accompanying HelloWorld can be found at
   https://github.com/apache/qpid-proton/pull/18
 Ongoing work is proceeding in my github account in branch cpp-work
   https://github.com/cliffjansen/qpid-proton/tree/cpp-work
 commit 1453f57ca3f446450ef654505548f1947cb7a0f1 adds listener support, 
 exceptions and a logging interface.
 The initial implementation will provide no thread safety guarantees, but the 
 bone structure should allow that to be added later with no API change.  I 
 still hold out hope of eventually allowing multiple threads processing 
 separate connections concurrently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)