[jira] [Commented] (PROTON-799) Provide the engine APIs in Ruby
[ https://issues.apache.org/jira/browse/PROTON-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571595#comment-14571595 ] ASF subversion and git services commented on PROTON-799: Commit 740b05ed54007e50da6dc90ac8089269a9aee5e6 in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=740b05e ] PROTON-799: Added the Event classes to the Ruby engine APIs. Provide the engine APIs in Ruby --- Key: PROTON-799 URL: https://issues.apache.org/jira/browse/PROTON-799 Project: Qpid Proton Issue Type: New Feature Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 Wrap the classes involved with the lower level driver APIs: * driver * listener * connector * transport * connection * sasl * session * event * link * delivery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-799) Provide the engine APIs in Ruby
[ https://issues.apache.org/jira/browse/PROTON-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571599#comment-14571599 ] ASF subversion and git services commented on PROTON-799: Commit ada57d89b0a900b8e8e30e0aec08ae95e145dcf3 in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ada57d8 ] PROTON-799: Adjusted the Ruby error macro Provide the engine APIs in Ruby --- Key: PROTON-799 URL: https://issues.apache.org/jira/browse/PROTON-799 Project: Qpid Proton Issue Type: New Feature Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 Wrap the classes involved with the lower level driver APIs: * driver * listener * connector * transport * connection * sasl * session * event * link * delivery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-799) Provide the engine APIs in Ruby
[ https://issues.apache.org/jira/browse/PROTON-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571600#comment-14571600 ] ASF subversion and git services commented on PROTON-799: Commit cedb476332fd3c73409563b74d17107463a0edcd in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=cedb476 ] PROTON-799: Test for the Wrapper and rbkey system Provide the engine APIs in Ruby --- Key: PROTON-799 URL: https://issues.apache.org/jira/browse/PROTON-799 Project: Qpid Proton Issue Type: New Feature Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 Wrap the classes involved with the lower level driver APIs: * driver * listener * connector * transport * connection * sasl * session * event * link * delivery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-799) Provide the engine APIs in Ruby
[ https://issues.apache.org/jira/browse/PROTON-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571596#comment-14571596 ] ASF subversion and git services commented on PROTON-799: Commit f5f943107f7cd76fcb23634f83cb516975be6dfb in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f5f9431 ] PROTON-799: Added the engine_send and engine_recv examples to Ruby. Provide the engine APIs in Ruby --- Key: PROTON-799 URL: https://issues.apache.org/jira/browse/PROTON-799 Project: Qpid Proton Issue Type: New Feature Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 Wrap the classes involved with the lower level driver APIs: * driver * listener * connector * transport * connection * sasl * session * event * link * delivery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-799) Provide the engine APIs in Ruby
[ https://issues.apache.org/jira/browse/PROTON-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571598#comment-14571598 ] ASF subversion and git services commented on PROTON-799: Commit ff235b88e5bf9a7a5c123f669377da4b0c03a2c9 in qpid-proton's branch refs/heads/master from [~mcpierce] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ff235b8 ] PROTON-799: Added yardopts Provide the engine APIs in Ruby --- Key: PROTON-799 URL: https://issues.apache.org/jira/browse/PROTON-799 Project: Qpid Proton Issue Type: New Feature Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 Wrap the classes involved with the lower level driver APIs: * driver * listener * connector * transport * connection * sasl * session * event * link * delivery -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570887#comment-14570887 ] ASF GitHub Bot commented on PROTON-881: --- Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/34#issuecomment-108444308 Hi Preston, sorry to take so long to look at this. My impulse here would be to avoid using a checked exception for HandlerException. I generally follow the advice that you should only use checked exceptions for error conditions that a programmer can anticipate and recover from, and I'm not sure that's the case here. It's nice to have the HandlerException for debugging and clarity so it's obvious when the handler is at fault rather than the reactor implementation itself, but I'm not sure how someone could catch and recover if it is thrown. Making it unchecked would also allow you to avoid the EventImpl changes you mention in your comment. Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: question about proton error philosophy
On Mon, 2013-09-16 at 13:23 -0400, Rafael Schloming wrote: FYI, as of 0.5 you should be able to use pn_messenger_error(pn_messenger_t *) to access the underlying error object (pn_error_t *) and clear it if an error has occurred. Making the application clear errno is pretty standard Unix practice too. I think the justification is that only the application can decide when a given error has been resolved, so only the application should clear errno. The library should not hide an error that the application has not explicitly indicated it is done with. If library functions call each other etc. the risk of losing an error is too great if they all start by assuming all OK. It it philosophically questionable but C is not a very philosophical language. --Rafael On Mon, Sep 16, 2013 at 12:40 PM, Michael Goulish mgoul...@redhat.comwrote: No, you're right. errno is never set to zero by any system call or library function ( That's from Linux doco. ) OK, I was just philosophically challenged. I think what confused me was the line in the current Proton C doc (about errno) that says an error code or zero if there is no error. I'll just remove that line. OK, I withdraw the question. ( I still don't like this philosophy, but the whole world is using it, and the whole world is bigger than I am... ) - Original Message - Do other APIs reset the errno? I could have sworn they didn't. On Mon, Sep 16, 2013 at 12:01 PM, Michael Goulish mgoul...@redhat.com wrote: I was expecting errno inside the messenger to be reset to 0 at the end of any successful API call. It isn't: instead it looks like the idea is that errno preserves the most recent error that happened, regardless of how long ago that might be. Is this intentional? I am having a hard time understanding why we would not want errno to always represent the messenger state as of the completion of the most recent API call. I would be happy to submit a patch to make it work this way, and see what people think - but not if I am merely exhibiting my own philosophical ignorance here. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino blog: Hiram Chirino's Bit Mojo
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: 0001-Rely-on-python-to-build-downloaded-tarball.patch removed `basepython` from tox.ini Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-895) Rely on python to build the downloaded tarball
[ https://issues.apache.org/jira/browse/PROTON-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Percoco updated PROTON-895: -- Attachment: (was: 0001-Rely-on-python-to-build-downloaded-tarball.patch) Rely on python to build the downloaded tarball -- Key: PROTON-895 URL: https://issues.apache.org/jira/browse/PROTON-895 Project: Qpid Proton Issue Type: Bug Reporter: Flavio Percoco Assignee: Ken Giusti Attachments: 0001-Rely-on-python-to-build-downloaded-tarball.patch Recently, a patch that made python-qpid-proton's setup.py download proton-c and build it whenever it's not found in the system. The patch relied on cmake to build the library as everyone would do when building proton-c. While that works, it's not the right, most pythonic, reliable way to do it. Some reasons why it's not a good thing: 1. It might overwrite a system qpid install if there's one and if the python-qpid-proton library is being installed in the system 2. It requires users - including CI systems, etc - to have cmake installed. 3. It does everything from outside the Python mechanism. The patch proposed in this bug changes the current behavior in favor of using Python's build extensions to compile the library. The patch follows the same steps as you'd do with cmake and it does it *just* for the downloaded tarball. If there's an installed proton-c library, there's nothing to do. If you're building it using cmake from a proton-c dir, it'll keep using cmake normally. The built library doesn't have the same name as the global one and it's installed along with the python binding instead of installing header files and the library itself system wide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570968#comment-14570968 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/34#issuecomment-108472809 No problem. I'll re-work and submit another PR based around HandlerException being unchecked. Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proton-c connect to topic on Apache Apollo server
I ran with PN_TRACE_FRM=1, and it returned the following log results. The connection has been working with Python but not with C. It seems to be some SASL issue, any thoughts? Python Log: [0x12d53c0]: - SASL [0x12d53c0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x12d53c0]: - SASL [0x12d53c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] [0x12d53c0]:0 - @sasl-outcome(68) [code=0] [0x12d53c0]: - AMQP [0x12d53c0]: - AMQP [0x12d53c0]:0 - @open(16) [container-id=3303f558-5f40-43a9-9a17-1788c1916ccb, hostname=127.0.0.1] [0x12d53c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x12d53c0]:0 - @attach(18) [name=topic://event, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=topic://event, durable=0, timeout=0, dynamic=false], target=@target(41) [address=topic://event, durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x12d53c0]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1024, drain=false] [0x12d53c0]:0 - @open(16) [container-id=mybroker, hostname=] [0x12d53c0]:0 - @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=1024, outgoing-window=1024, handle-max=1024] [0x12d53c0]:0 - @attach(18) [name=topic://event, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=topic://event], target=@target(41) [address=topic://event], incomplete-unsettled=false, initial-delivery-count=0] C Log: [0xa34500]: - SASL [0xa34500]:0 - @sasl-init(65) [initial-response=b] [0xa34500]: - SASL [0xa34500]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]] -- View this message in context: http://qpid.2158936.n2.nabble.com/Proton-c-connect-to-topic-on-Apache-Apollo-server-tp7625612p7625673.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[GitHub] qpid-proton pull request: PROTON-881: Graceful handling of runtime...
Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/34#issuecomment-108472809 No problem. I'll re-work and submit another PR based around HandlerException being unchecked. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570969#comment-14570969 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/34 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-881: Graceful handling of runtime...
Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/34 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Proton-c connect to topic on Apache Apollo server
On 06/03/2015 04:14 PM, logty wrote: I ran with PN_TRACE_FRM=1, and it returned the following log results. The connection has been working with Python but not with C. It seems to be some SASL issue, any thoughts? The c client is not setting the mechanism chosen which is mandatory. What version of proton are you using (and on what platform)? C Log: [0xa34500]: - SASL [0xa34500]:0 - @sasl-init(65) [initial-response=b] [0xa34500]: - SASL [0xa34500]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
Re: Proton-c connect to topic on Apache Apollo server
I am using proton 1.5.2 on redhat 6.6. -- View this message in context: http://qpid.2158936.n2.nabble.com/Proton-c-connect-to-topic-on-Apache-Apollo-server-tp7625612p7625691.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Proton-c connect to topic on Apache Apollo server
On 06/03/2015 06:17 PM, logty wrote: I am using proton 1.5.2 on redhat 6.6. That can't be right, I don't think, as the latest release was 0.9.1.
Re: question about proton error philosophy
It it philosophically questionable but C is not a very philosophical language. I beg to differ. Here are some famous thoughts concerning the C language by one early practioner, that greatest of all Roman philosophers, the incomparable Ibid. Non teneas aurum totum quod splendet ut aurum, et scribe in C. Minima maxima sunt, sic haec scriberem C. Mutantur omnia nos et mutamur in illis, nisi lingua C.
[jira] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572132#comment-14572132 ] ASF subversion and git services commented on PROTON-334: Commit 89ef63b46f35c6916f1e134a500fdf372bb5438d in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=89ef63b ] PROTON-334: Mark transport as authenticated on client side - Make sure we don't send init SASL frames if an error happened SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571362#comment-14571362 ] ASF subversion and git services commented on PROTON-865: Commit 8074793b84a6402b01f3639e8cf8fed6b5ba54cc 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=8074793 ] PROTON-865: Example and cmake cleanup, minor code cleanup. - Optionally enable C++ in top level cmake for examplesb. Still works without a C++ compiler. - Move cpp examples to the /examples dir, renamed for consistent exe naming conventions. - Integrate example build auto-test with cmake - Improved exception handling - Simplified exception handling. - Removed nascent logging code, logging should be handled centrally in C library. 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)
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571359#comment-14571359 ] ASF subversion and git services commented on PROTON-865: Commit 3c0c90f74c053657d04cd7ba6f357f851c101999 in qpid-proton's branch refs/heads/cjansen-cpp-client from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3c0c90f ] PROTON-865: Message properties, Acking and Delivery 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)
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571361#comment-14571361 ] ASF subversion and git services commented on PROTON-865: Commit d56c5d7664334af3126e1509bef5791593a08c35 in qpid-proton's branch refs/heads/cjansen-cpp-client from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d56c5d7 ] PROTON-865: Blocking sender functionality and handler per connection 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)
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571358#comment-14571358 ] ASF subversion and git services commented on PROTON-865: Commit 648f7b36caa26e8078b92b50391d2e9f23e16080 in qpid-proton's branch refs/heads/cjansen-cpp-client from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=648f7b3 ] PROTON-865: most of MessagingAdapter in place, SimpleSend/Recv 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)
[GitHub] qpid-proton pull request: C++ binding for proton.
GitHub user alanconway opened a pull request: https://github.com/apache/qpid-proton/pull/35 C++ binding for proton. Cliff Jansen has been working on an event-driven C++ binding for proton, similar to the python binding. The work is not complete but I think it is almost ready to move to trunk for easier access. Please see proton-c/bindings/cpp/README.md for a TODO list. I'll be working on the TODO list this week and will move the binding to trunk next week if there are no objecctions. Any other comments are most welcome. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/qpid-proton cjansen-cpp-client Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/35.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #35 commit ad7c9778f4ea33a6ca982ac4fea5178b0320b24d Author: Cliff Jansen cliffjan...@apache.org Date: 2015-04-30T18:22:03Z PROTON-865: new cjansen-cpp-client branch for fledgling C++ client code using the event reactor commit 648f7b36caa26e8078b92b50391d2e9f23e16080 Author: Cliff Jansen cliffjan...@apache.org Date: 2015-05-05T13:48:48Z PROTON-865: most of MessagingAdapter in place, SimpleSend/Recv commit 3c0c90f74c053657d04cd7ba6f357f851c101999 Author: Cliff Jansen cliffjan...@apache.org Date: 2015-05-07T14:06:43Z PROTON-865: Message properties, Acking and Delivery commit e8acc1e5f58975dc9d1d99d779f5e3c77289a4b1 Author: Cliff Jansen cliffjan...@apache.org Date: 2015-05-12T02:29:53Z PROTON-865: Added basic Terminus, Broker.cpp example commit d56c5d7664334af3126e1509bef5791593a08c35 Author: Cliff Jansen cliffjan...@apache.org Date: 2015-05-20T14:54:03Z PROTON-865: Blocking sender functionality and handler per connection commit 8074793b84a6402b01f3639e8cf8fed6b5ba54cc Author: Alan Conway acon...@redhat.com Date: 2015-06-01T22:03:36Z PROTON-865: Example and cmake cleanup, minor code cleanup. - Optionally enable C++ in top level cmake for examplesb. Still works without a C++ compiler. - Move cpp examples to the /examples dir, renamed for consistent exe naming conventions. - Integrate example build auto-test with cmake - Improved exception handling - Simplified exception handling. - Removed nascent logging code, logging should be handled centrally in C library. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
