[jira] [Assigned] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk reassigned PROTON-2091:
--
Assignee: Jiri Daněk
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914654#comment-16914654
]
ASF GitHub Bot commented on PROTON-2091:
jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in
python/examples and reformat for PEP8
URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524471523
Ok, it is trivial enough it does not need a test. Adding this as a python
doctest would be similarly distracting, I guess
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8
jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8 URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524471523 Ok, it is trivial enough it does not need a test. Adding this as a python doctest would be similarly distracting, I guess This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914651#comment-16914651
]
ASF GitHub Bot commented on PROTON-2091:
astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in
python/examples and reformat for PEP8
URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524470568
Please remove it - this is meant to be example code. No other example has
test code included.
If you really think we need to include unit tests for something that you
think is complex enough to need it then use a testing tool that can extract
unit tests from comments and put the unit test comment with the class/function
that is being tested.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8
astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8 URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524470568 Please remove it - this is meant to be example code. No other example has test code included. If you really think we need to include unit tests for something that you think is complex enough to need it then use a testing tool that can extract unit tests from comments and put the unit test comment with the class/function that is being tested. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914649#comment-16914649
]
ASF GitHub Bot commented on PROTON-2091:
jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in
python/examples and reformat for PEP8
URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524469661
I meant to keep the test code there. It will only execute if user does
`python -m unittest discover`, otherwise it is inert.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8
jdanekrh commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8 URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524469661 I meant to keep the test code there. It will only execute if user does `python -m unittest discover`, otherwise it is inert. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914648#comment-16914648
]
ASF GitHub Bot commented on PROTON-2091:
astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in
python/examples and reformat for PEP8
URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524469383
I think you left extraneous testing code in the bottom of the file.
Otherwise looks good to me.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8
astitcher commented on issue #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8 URL: https://github.com/apache/qpid-proton/pull/188#issuecomment-524469383 I think you left extraneous testing code in the bottom of the file. Otherwise looks good to me. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2091) [python] example broker never removes empty queues
[
https://issues.apache.org/jira/browse/PROTON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914644#comment-16914644
]
ASF GitHub Bot commented on PROTON-2091:
jdanekrh commented on pull request #188: PROTON-2091: fix `len(queue)` in
python/examples and reformat for PEP8
URL: https://github.com/apache/qpid-proton/pull/188
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [python] example broker never removes empty queues
> --
>
> Key: PROTON-2091
> URL: https://issues.apache.org/jira/browse/PROTON-2091
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.29.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> {code:python:title=python/examples/broker.py}
> def unsubscribe(self, consumer):
> if consumer in self.consumers:
> self.consumers.remove(consumer)
> return len(self.consumers) == 0 and (self.dynamic or
> self.queue.count == 0)
> {code}
> Here, {{self.queue.count == 0}} can never be {{True}} (because method
> reference != integer). This means that broker will never drop the {{Queue}}
> object.
> Functionality wise, the impact of this is insignificant, given the uses of
> the code (stand-in for real broker when running simple messaging examples).
> It has compatibility implications, however, because {{self.queue.count}} is a
> Python 2.7 addition and on Python 2.6 accessing undefined property will raise
> exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jdanekrh opened a new pull request #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8
jdanekrh opened a new pull request #188: PROTON-2091: fix `len(queue)` in python/examples and reformat for PEP8 URL: https://github.com/apache/qpid-proton/pull/188 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2091) [python] example broker never removes empty queues
Jiri Daněk created PROTON-2091:
--
Summary: [python] example broker never removes empty queues
Key: PROTON-2091
URL: https://issues.apache.org/jira/browse/PROTON-2091
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: proton-c-0.29.0
Reporter: Jiri Daněk
{code:python:title=python/examples/broker.py}
def unsubscribe(self, consumer):
if consumer in self.consumers:
self.consumers.remove(consumer)
return len(self.consumers) == 0 and (self.dynamic or self.queue.count
== 0)
{code}
Here, {{self.queue.count == 0}} can never be {{True}} (because method reference
!= integer). This means that broker will never drop the {{Queue}} object.
Functionality wise, the impact of this is insignificant, given the uses of the
code (stand-in for real broker when running simple messaging examples).
It has compatibility implications, however, because {{self.queue.count}} is a
Python 2.7 addition and on Python 2.6 accessing undefined property will raise
exception and crash the broker.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914631#comment-16914631 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317299565 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: I went through this list with @ssorj, but if he agrees, we should remove it. Better now than after we release this. It is better to add bits than to have to retract/deprecate them later. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317299565 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: I went through this list with @ssorj, but if he agrees, we should remove it. Better now than after we release this. It is better to add bits than to have to retract/deprecate them later. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914628#comment-16914628 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317299082 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the Review comment: Thanks, x2 in fact! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914627#comment-16914627 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298952 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: I changed this to read: > When an event handler callback is called by the library, an Event object is > passed to it which contains an object associated with the event. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was se
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317299082 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the Review comment: Thanks, x2 in fact! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298952 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: I changed this to read: > When an event handler callback is called by the library, an Event object is > passed to it which contains an object associated with the event. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914626#comment-16914626 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298694 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the Review comment: Thank you for the clarification. I changed this to read: > This also includes actions such as settling the > delivery (ie causing the delivery status to be forgotten when it is no longer needed). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298694 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the Review comment: Thank you for the clarification. I changed this to read: > This also includes actions such as settling the > delivery (ie causing the delivery status to be forgotten when it is no longer needed). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914625#comment-16914625 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298210 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Pyth
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914623#comment-16914623 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298104 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914624#comment-16914624 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298149 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Proje
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298014 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: + +* **on_message()**: This callback indicates that a message has been received. The message and its delivery object may +be retreived, and if needed, the message can be either accepted or rejected. + +Many other events exist for the handling of transactions and other message events and errors, and if present in +your handler will be called as the corresponding events arise. See the :ref:`tutorial` for examples of handling +some other events. + +Several event handlers
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298210 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298104 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: d
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914621#comment-16914621 ] ASF GitHub Bot commented on PROTON-2086: kpvdr commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298014 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: + +* **on_message()**: This callback indicates that a message has been received. The message and its delivery object may +be retreived, and if needed, the message can be either accepted or rejected. + +Many other events exist f
[GitHub] [qpid-proton] kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
kpvdr commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317298149 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: Review comment: Agreed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914619#comment-16914619 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317291003 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: Review comment: Again as sending messages This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and u
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914618#comment-16914618 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317293874 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: As above I don't think we should document anything other than MessagingHandler & after consideration TransactionHandler/TransactionClientHandler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914617#comment-16914617 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317294349 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: Bear in mind this is because MessagingHandler actually aggregates all the other functionality anyway because of the way the event dispatch works. So all the default functionality is that of MessagingHandler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914616#comment-16914616 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317293384 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: + +* **on_message()**: This callback indicates that a message has been received. The message and its delivery object may +be retreived, and if needed, the message can be either accepted or rejected. + +Many other events exi
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914613#comment-16914613 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289764 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: So strike 'in some cases' This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@q
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914614#comment-16914614 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317290849 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: Review comment: 'need' -> 'may need' (as above). Or 'usually' - but it's not an invariable rule. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 >
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914615#comment-16914615 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317290561 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: Review comment: Strike 'should' insert 'may' or 'can'. Which handlers to use will be very dependent on the application and exactly which guarantees it needs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: pyth
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317293384 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: + +* **on_message()**: This callback indicates that a message has been received. The message and its delivery object may +be retreived, and if needed, the message can be either accepted or rejected. + +Many other events exist for the handling of transactions and other message events and errors, and if present in +your handler will be called as the corresponding events arise. See the :ref:`tutorial` for examples of handling +some other events. + +Several event handl
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317294349 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: Bear in mind this is because MessagingHandler actually aggregates all the other functionality anyway because of the way the event dispatch works. So all the default functionality is that of MessagingHandler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317293874 ## File path: python/docs/proton.handlers.rst ## @@ -0,0 +1,106 @@ +## +Module ``proton.handlers`` +## + +.. currentmodule:: proton.handlers + +Module Summary +## + +| + +.. autosummary:: + +MessagingHandler +EndpointStateHandler Review comment: As above I don't think we should document anything other than MessagingHandler & after consideration TransactionHandler/TransactionClientHandler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289764 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: So strike 'in some cases' This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317290849 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: Review comment: 'need' -> 'may need' (as above). Or 'usually' - but it's not an invariable rule. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317291003 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: + +* **on_start()**: This indicates that the event loop in the container has started, and that a new sender and/or +receiver may now be created. + +To send a message, the following events need to be handled: + +* **on_sendable()**: This callback indicates that send credit has now been set by the receiver, and that a message may +now be sent. +* **on_accepted()**: This callback indicates that a message has been received and accepted by the receiving peer. + +To receive a message, the following event need to be handled: Review comment: Again as sending messages This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317290561 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, +when a message is received, the event object will have the property ``event.message`` by which the message itself may +be obtained. See :class:`proton.Event` for more details. + +The following are some of the important event callbacks that should be implemented by a developer: Review comment: Strike 'should' insert 'may' or 'can'. Which handlers to use will be very dependent on the application and exactly which guarantees it needs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1383) system_tests_policy is timing out
[ https://issues.apache.org/jira/browse/DISPATCH-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1383. --- Fix Version/s: 1.9.0 Resolution: Fixed > system_tests_policy is timing out > - > > Key: DISPATCH-1383 > URL: https://issues.apache.org/jira/browse/DISPATCH-1383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.8.0 >Reporter: Fernando Giorgetti >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > We are seeing system_tests_policy timing out on RHEL6, RHEL7 and RHEL8 > platforms. > This is happening with latest bits from master branch and latest proton > (downstream). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914602#comment-16914602 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289512 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the Review comment: 'settling' is a term of art within the AMQP spec referring to the act of forgetting about a delivery when you no longer need to remember it because we no longer care about it receipt status and no longer need to retry the delivery. It is separate from the concepts of terminal delivery state - Accept, Reject, Release etc. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914601#comment-16914601 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289496 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: Really the only point of the Event object passed to the handlers is to get the object to which the event pertains. It also contains the event handled (but we know what that is because clearly we're already in the appropriate handler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These sho
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289496 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the +delivery, a mechanism by which each peer can verify that the message has been properly received and is either accepted +or rejected. The delivery class may be found at :class:`proton.Delivery`. The delivery object is most commonly obtained +when a message-related event occurs through the event object. See `Event Handlers`_ below. + +Event Handlers +-- + +A **handler** is a class that handles events associated with the sending and receiving of messages. This includes +callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing +of the connection over which messages are sent. An application developer must handle some key events to +successfully send and receive messages. When an event handler callback is called by the library, an Event object is +passed to it which contains details of the event, and in some cases, objects associated with the event. For example, Review comment: Really the only point of the Event object passed to the handlers is to get the object to which the event pertains. It also contains the event handled (but we know what that is because clearly we're already in the appropriate handler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317289512 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the +status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the Review comment: 'settling' is a term of art within the AMQP spec referring to the act of forgetting about a delivery when you no longer need to remember it because we no longer care about it receipt status and no longer need to retry the delivery. It is separate from the concepts of terminal delivery state - Accept, Reject, Release etc. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2086) Move Python API docs to use Sphinx
[ https://issues.apache.org/jira/browse/PROTON-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914586#comment-16914586 ] ASF GitHub Bot commented on PROTON-2086: astitcher commented on pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317287382 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the Review comment: typo - delivery This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Move Python API docs to use Sphinx > -- > > Key: PROTON-2086 > URL: https://issues.apache.org/jira/browse/PROTON-2086 > Project: Qpid Proton > Issue Type: Task > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the Python API docs are generated using ePyDoc. These should be > switched to using Sphinx. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx
astitcher commented on a change in pull request #186: PROTON-2086: Changed API documentation from epydoc to Sphinx URL: https://github.com/apache/qpid-proton/pull/186#discussion_r317287382 ## File path: python/docs/index.rst ## @@ -1,11 +1,134 @@ -Apache Qpid Proton: python documentation - + +Qpid Proton Python API Documentation + -Contents: +The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications +that send and receive AMQP messages. +*** +Modules +*** .. toctree:: :maxdepth: 2 - tutorial + proton + proton.handlers + proton.reactor + proton.utils + +* +About AMQP and the Qpid Proton Python API +* + +.. toctree:: + :maxdepth: 1 + overview + tutorial + +Key API Features + + + * Event-driven API + * SSL/TLS secured communication + * SASL authentication + * Automatic reconnect and failover + * Seamless conversion between AMQP and Python data types + * AMQP 1.0 + +Basic API Concepts +== + +The Qpid Python client API and library allows applications to send and receive AMQP messages. See :ref:`overview` +for a more detailed explanation. + +Containers +-- + +Messages are transferred between connected peers (or nodes) using **senders** and **receivers**. Each sender +or receiver is established over a **connection**. Each connection is established between two unique **containers**, +the entry point for the API. The container class :class:`proton.reactor.Container` is found in the ``proton.reactor`` +module. + +Senders +--- + +The peer that sends messages uses a **sender** to send messages, which includes the target queue or topic which is +to receive the messages. The sender may be found at :class:`proton.Sender`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_sender`. + +Receivers +- + +The peer that receives messages uses a **receiver** to receive messages, and includes a source queue or topic from +which to receive messages. The receiver may be found at :class:`proton.Receiver`. Note that senders are most commonly +obtained by using the convenience method :meth:`proton.reactor.Container.create_receiver`. + +Message Delivery + + +The process of sending a message is known as **delevery**. Each sent message has a delivry object which tracks the Review comment: typo - delivery This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher edited a comment on issue #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking
astitcher edited a comment on issue #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking URL: https://github.com/apache/qpid-proton/pull/187#issuecomment-524436160 Can you explain your specific situation more because this fix doesn't entirely make sense: These libraries should be LINK_PRIVATE as far as cmake semantics are concerned because they provide symbols only to the qpid-proton-cpp library itself and are not needed by any of its clients. LINK_PUBLIC means that any client of qpid-proton-cpp would link with these libraries and this is not needed or desired. Are you perhaps trying to build the cpp directory of the qpid-proton tree by itself? Currently the only way to build the C++ API is as part of the full tree build. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on issue #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking
astitcher commented on issue #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking URL: https://github.com/apache/qpid-proton/pull/187#issuecomment-524436160 Can you explain your specific situation more because this fix doesn't entirely make sense: These libraries should be LINK_PRIVATE as far as cmake semantics are concerned because they provide symbols only to the qpid-proton-cpp library itself and are not needed by any of it's clients. LINK_PUBLIC means that any client of qpid-proton-cpp would need to explicitly link with these libraries and this is not needed or desired. Are you perhaps trying to build the cpp directory of the qpid-proton tree by itself? Currently the only way to build the C++ API is as part of the full tree build. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] ffontaine opened a new pull request #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking
ffontaine opened a new pull request #187: cpp/CMakeLists.txt: fix qpid-proton-cpp linking URL: https://github.com/apache/qpid-proton/pull/187 gpid-proton-cpp must use LINK_PUBLIC to link with qpid-proton-core and qpid-proton-proactor otherwise build will fail if those libraries are not yet installed on the system: [ 81%] Linking CXX executable value_test /home/fabrice/buildroot/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: warning: libqpid-proton-proactor.so.1, needed by libqpid-proton-cpp.so.12.6.0, not found (try using -rpath or -rpath-link) /home/fabrice/buildroot/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: warning: libqpid-proton-core.so.10, needed by libqpid-proton-cpp.so.12.6.0, not found (try using -rpath or -rpath-link) /home/fabrice/buildroot/output/host/lib/gcc/arm-buildroot-linux-uclibcgnueabihf/8.3.0/../../../../arm-buildroot-linux-uclibcgnueabihf/bin/ld: libqpid-proton-cpp.so.12.6.0: undefined reference to `pn_data_put_described' Signed-off-by: Fabrice Fontaine This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8349) [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test suite against external broker
[
https://issues.apache.org/jira/browse/QPID-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914245#comment-16914245
]
ASF subversion and git services commented on QPID-8349:
---
Commit 1d327d9b1ad316c0d78d6fe78a96a36108ef274c in qpid-broker-j's branch
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=1d327d9 ]
QPID-8349: [Tests][AMQP 1.0] Report decoding errors
> [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test
> suite against external broker
> ---
>
> Key: QPID-8349
> URL: https://issues.apache.org/jira/browse/QPID-8349
> Project: Qpid
> Issue Type: Task
> Components: Java Tests
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The existing protocol test framework allows to run test against external
> broker only when annotation {{RunBrokerAdmin}} is added to the test class
> with a type pointing to external broker admin type.
> With this approach the implemented test can only be executed with a
> particular broker admin type.
> The original intention of protocol tests was to allow running protocol tests
> against any AMQP compliment broker. The specific broker admin needs to be
> injected into the test framework.
> Currently, we have "external" and "embedded" broker admin type, but, there is
> no way to execute protocol tests even against external Qpid broker.
> We need to modify protocol test framework to allow running existing tests
> against external broker
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8349) [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test suite against external broker
[
https://issues.apache.org/jira/browse/QPID-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914248#comment-16914248
]
ASF subversion and git services commented on QPID-8349:
---
Commit 1d8e03306dca63405744126991b84eadfcc92b6b in qpid-broker-j's branch
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=1d8e033 ]
QPID-8349: [Tests][AMQP 1.0] Add ability to close connections without asserting
peer responses
> [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test
> suite against external broker
> ---
>
> Key: QPID-8349
> URL: https://issues.apache.org/jira/browse/QPID-8349
> Project: Qpid
> Issue Type: Task
> Components: Java Tests
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The existing protocol test framework allows to run test against external
> broker only when annotation {{RunBrokerAdmin}} is added to the test class
> with a type pointing to external broker admin type.
> With this approach the implemented test can only be executed with a
> particular broker admin type.
> The original intention of protocol tests was to allow running protocol tests
> against any AMQP compliment broker. The specific broker admin needs to be
> injected into the test framework.
> Currently, we have "external" and "embedded" broker admin type, but, there is
> no way to execute protocol tests even against external Qpid broker.
> We need to modify protocol test framework to allow running existing tests
> against external broker
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8349) [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test suite against external broker
[
https://issues.apache.org/jira/browse/QPID-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914244#comment-16914244
]
ASF subversion and git services commented on QPID-8349:
---
Commit af83b6db0463d095f626592e15a9e4f5297281f7 in qpid-broker-j's branch
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=af83b6d ]
QPID-8349: [Tests][AMQP 1.0] Fix ExistingQueueAdmin
> [Broker-J][AMQP 1.0][Tests] Improve protocol tests to be able to run the test
> suite against external broker
> ---
>
> Key: QPID-8349
> URL: https://issues.apache.org/jira/browse/QPID-8349
> Project: Qpid
> Issue Type: Task
> Components: Java Tests
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The existing protocol test framework allows to run test against external
> broker only when annotation {{RunBrokerAdmin}} is added to the test class
> with a type pointing to external broker admin type.
> With this approach the implemented test can only be executed with a
> particular broker admin type.
> The original intention of protocol tests was to allow running protocol tests
> against any AMQP compliment broker. The specific broker admin needs to be
> injected into the test framework.
> Currently, we have "external" and "embedded" broker admin type, but, there is
> no way to execute protocol tests even against external Qpid broker.
> We need to modify protocol test framework to allow running existing tests
> against external broker
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8350) [Broker-J][AMQP 1.0][Tests] Fix protocol tests
[
https://issues.apache.org/jira/browse/QPID-8350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914246#comment-16914246
]
ASF subversion and git services commented on QPID-8350:
---
Commit 1e416ebf2dc1a91ea3f1dc7332a66ee9de9e8316 in qpid-broker-j's branch
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=1e416eb ]
QPID-8350: [Tests][AMQP 1.0] Ignore sporadic flow perfromatives in transfer
tests
> [Broker-J][AMQP 1.0][Tests] Fix protocol tests
> --
>
> Key: QPID-8350
> URL: https://issues.apache.org/jira/browse/QPID-8350
> Project: Qpid
> Issue Type: Task
> Components: Java Tests
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> Existing protocol tests works on a number of assumptions which are valid for
> Qpid Broker-J but when they are run against different broker the majority of
> test fail straight away due to various reasons like "not respecting
> counterpart settings in attach {{initial-delivery-count}}", lacking
> assertions about published/consumed messages, etc.
> As part of this JIRA we need to make tests amqp broker neutral and amqp
> complient
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8350) [Broker-J][AMQP 1.0][Tests] Fix protocol tests
[
https://issues.apache.org/jira/browse/QPID-8350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914247#comment-16914247
]
ASF subversion and git services commented on QPID-8350:
---
Commit 605e727da226b503db95d3d2078e6196caf1aab6 in qpid-broker-j's branch
refs/heads/master from Alex Rudyy
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=605e727 ]
QPID-8350: [Tests][AMQP 1.0] Improve handling of amqp errors in tests
> [Broker-J][AMQP 1.0][Tests] Fix protocol tests
> --
>
> Key: QPID-8350
> URL: https://issues.apache.org/jira/browse/QPID-8350
> Project: Qpid
> Issue Type: Task
> Components: Java Tests
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> Existing protocol tests works on a number of assumptions which are valid for
> Qpid Broker-J but when they are run against different broker the majority of
> test fail straight away due to various reasons like "not respecting
> counterpart settings in attach {{initial-delivery-count}}", lacking
> assertions about published/consumed messages, etc.
> As part of this JIRA we need to make tests amqp broker neutral and amqp
> complient
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
