Repository: qpid-proton Updated Branches: refs/heads/master 0b7718c74 -> 26a0622c0
NO-JIRA: integrate tutorial generation with the docs target from the main build Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/26a0622c Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/26a0622c Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/26a0622c Branch: refs/heads/master Commit: 26a0622c0b2977f2c02d5acbccc06e0cf5c3d089 Parents: 0b7718c Author: Gordon Sim <[email protected]> Authored: Wed May 27 11:38:53 2015 +0100 Committer: Gordon Sim <[email protected]> Committed: Wed May 27 11:39:46 2015 +0100 ---------------------------------------------------------------------- proton-c/bindings/python/CMakeLists.txt | 12 + proton-c/bindings/python/docs/Makefile | 153 ---------- proton-c/bindings/python/docs/README | 5 - proton-c/bindings/python/docs/conf.py | 242 +++++++++++++++ proton-c/bindings/python/docs/index.rst | 11 + proton-c/bindings/python/docs/make.bat | 190 ------------ proton-c/bindings/python/docs/overview.rst | 160 ++++++++++ proton-c/bindings/python/docs/source/conf.py | 242 --------------- proton-c/bindings/python/docs/source/index.rst | 24 -- .../bindings/python/docs/source/overview.rst | 161 ---------- .../bindings/python/docs/source/reference.rst | 44 --- .../bindings/python/docs/source/tutorial.rst | 301 ------------------- proton-c/bindings/python/docs/tutorial.rst | 301 +++++++++++++++++++ 13 files changed, 726 insertions(+), 1120 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/CMakeLists.txt ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/CMakeLists.txt b/proton-c/bindings/python/CMakeLists.txt index 2886326..4f15aac 100644 --- a/proton-c/bindings/python/CMakeLists.txt +++ b/proton-c/bindings/python/CMakeLists.txt @@ -94,6 +94,18 @@ if (EPYDOC_EXE) ${OPTIONAL_ARG}) endif (EPYDOC_EXE) +find_program(SPHINX_EXE sphinx-build) +mark_as_advanced (SPHINX_EXE) +if (SPHINX_EXE) + add_custom_target(tutorial-py COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../../env.py -- + PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}:${CMAKE_CURRENT_SOURCE_DIR} + ${SPHINX_EXE} -b html ${CMAKE_CURRENT_SOURCE_DIR}/docs ${CMAKE_CURRENT_BINARY_DIR}/tutorial) + add_dependencies(docs tutorial-py) + install(DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/tutorial/" + DESTINATION "${PROTON_SHARE}/docs/tutorial-py" + COMPONENT documentation) +endif (SPHINX_EXE) + install(FILES ${CPROTON_ARTIFACTS} DESTINATION ${PYTHON_SITEARCH_PACKAGES} COMPONENT Python) http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/Makefile ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/Makefile b/proton-c/bindings/python/docs/Makefile deleted file mode 100644 index d6c6886..0000000 --- a/proton-c/bindings/python/docs/Makefile +++ /dev/null @@ -1,153 +0,0 @@ -# Makefile for Sphinx documentation -# - -# You can set these variables from the command line. -SPHINXOPTS = -SPHINXBUILD = sphinx-build -PAPER = -BUILDDIR = build - -# Internal variables. -PAPEROPT_a4 = -D latex_paper_size=a4 -PAPEROPT_letter = -D latex_paper_size=letter -ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source -# the i18n builder cannot share the environment and doctrees with the others -I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source - -.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext - -help: - @echo "Please use \`make <target>' where <target> is one of" - @echo " html to make standalone HTML files" - @echo " dirhtml to make HTML files named index.html in directories" - @echo " singlehtml to make a single large HTML file" - @echo " pickle to make pickle files" - @echo " json to make JSON files" - @echo " htmlhelp to make HTML files and a HTML help project" - @echo " qthelp to make HTML files and a qthelp project" - @echo " devhelp to make HTML files and a Devhelp project" - @echo " epub to make an epub" - @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" - @echo " latexpdf to make LaTeX files and run them through pdflatex" - @echo " text to make text files" - @echo " man to make manual pages" - @echo " texinfo to make Texinfo files" - @echo " info to make Texinfo files and run them through makeinfo" - @echo " gettext to make PO message catalogs" - @echo " changes to make an overview of all changed/added/deprecated items" - @echo " linkcheck to check all external links for integrity" - @echo " doctest to run all doctests embedded in the documentation (if enabled)" - -clean: - -rm -rf $(BUILDDIR)/* - -html: - $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." - -dirhtml: - $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." - -singlehtml: - $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml - @echo - @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." - -pickle: - $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle - @echo - @echo "Build finished; now you can process the pickle files." - -json: - $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json - @echo - @echo "Build finished; now you can process the JSON files." - -htmlhelp: - $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp - @echo - @echo "Build finished; now you can run HTML Help Workshop with the" \ - ".hhp project file in $(BUILDDIR)/htmlhelp." - -qthelp: - $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp - @echo - @echo "Build finished; now you can run "qcollectiongenerator" with the" \ - ".qhcp project file in $(BUILDDIR)/qthelp, like this:" - @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ApacheQpidProton.qhcp" - @echo "To view the help file:" - @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ApacheQpidProton.qhc" - -devhelp: - $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp - @echo - @echo "Build finished." - @echo "To view the help file:" - @echo "# mkdir -p $$HOME/.local/share/devhelp/ApacheQpidProton" - @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ApacheQpidProton" - @echo "# devhelp" - -epub: - $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub - @echo - @echo "Build finished. The epub file is in $(BUILDDIR)/epub." - -latex: - $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex - @echo - @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." - @echo "Run \`make' in that directory to run these through (pdf)latex" \ - "(use \`make latexpdf' here to do that automatically)." - -latexpdf: - $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex - @echo "Running LaTeX files through pdflatex..." - $(MAKE) -C $(BUILDDIR)/latex all-pdf - @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." - -text: - $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text - @echo - @echo "Build finished. The text files are in $(BUILDDIR)/text." - -man: - $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man - @echo - @echo "Build finished. The manual pages are in $(BUILDDIR)/man." - -texinfo: - $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo - @echo - @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." - @echo "Run \`make' in that directory to run these through makeinfo" \ - "(use \`make info' here to do that automatically)." - -info: - $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo - @echo "Running Texinfo files through makeinfo..." - make -C $(BUILDDIR)/texinfo info - @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." - -gettext: - $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale - @echo - @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." - -changes: - $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes - @echo - @echo "The overview file is in $(BUILDDIR)/changes." - -linkcheck: - $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck - @echo - @echo "Link check complete; look for any errors in the above output " \ - "or in $(BUILDDIR)/linkcheck/output.txt." - -doctest: - $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest - @echo "Testing of doctests in the sources finished, look at the " \ - "results in $(BUILDDIR)/doctest/output.txt." http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/README ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/README b/proton-c/bindings/python/docs/README deleted file mode 100644 index a8eeeec..0000000 --- a/proton-c/bindings/python/docs/README +++ /dev/null @@ -1,5 +0,0 @@ -Note: The generation of the documentation is not yet hooked into the -overall build. The docs are based on shpinx which you will need to -have installed. To build the docs you also need to have the proton lib -on your PYTHONPATH. Then simply run `make html` and the html files are -generated under build here. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/conf.py ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/conf.py b/proton-c/bindings/python/docs/conf.py new file mode 100644 index 0000000..4c76753 --- /dev/null +++ b/proton-c/bindings/python/docs/conf.py @@ -0,0 +1,242 @@ +# -*- coding: utf-8 -*- +# +# Apache Qpid Proton documentation build configuration file, created by +# sphinx-quickstart on Mon Feb 16 14:13:09 2015. +# +# This file is execfile()d with the current directory set to its containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +import sys, os + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +#sys.path.insert(0, os.path.abspath('.')) + +# -- General configuration ----------------------------------------------------- + +# If your documentation needs a minimal Sphinx version, state it here. +#needs_sphinx = '1.0' + +# Add any Sphinx extension module names here, as strings. They can be extensions +# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. +extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo'] + +# Add any paths that contain templates here, relative to this directory. +#templates_path = ['_templates'] + +# The suffix of source filenames. +source_suffix = '.rst' + +# The encoding of source files. +#source_encoding = 'utf-8-sig' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = u'Apache Qpid Proton' +copyright = u'2015, Apache Qpid' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = '0.10' +# The full version, including alpha/beta/rc tags. +release = '0.10' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +#language = None + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +#today = '' +# Else, today_fmt is used as the format for a strftime call. +#today_fmt = '%B %d, %Y' + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +exclude_patterns = [] + +# The reST default role (used for this markup: `text`) to use for all documents. +#default_role = None + +# If true, '()' will be appended to :func: etc. cross-reference text. +#add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +#add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +#show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# A list of ignored prefixes for module index sorting. +#modindex_common_prefix = [] + + +# -- Options for HTML output --------------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +html_theme = 'sphinxdoc' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +#html_theme_options = {} + +# Add any paths that contain custom themes here, relative to this directory. +#html_theme_path = [] + +# The name for this set of Sphinx documents. If None, it defaults to +# "<project> v<release> documentation". +#html_title = None + +# A shorter title for the navigation bar. Default is the same as html_title. +#html_short_title = None + +# The name of an image file (relative to this directory) to place at the top +# of the sidebar. +#html_logo = None + +# The name of an image file (within the static path) to use as favicon of the +# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# pixels large. +#html_favicon = None + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +#html_static_path = ['_static'] + +# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, +# using the given strftime format. +#html_last_updated_fmt = '%b %d, %Y' + +# If true, SmartyPants will be used to convert quotes and dashes to +# typographically correct entities. +#html_use_smartypants = True + +# Custom sidebar templates, maps document names to template names. +#html_sidebars = {} + +# Additional templates that should be rendered to pages, maps page names to +# template names. +#html_additional_pages = {} + +# If false, no module index is generated. +#html_domain_indices = True + +# If false, no index is generated. +#html_use_index = True + +# If true, the index is split into individual pages for each letter. +#html_split_index = False + +# If true, links to the reST sources are added to the pages. +#html_show_sourcelink = True + +# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. +#html_show_sphinx = True + +# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. +#html_show_copyright = True + +# If true, an OpenSearch description file will be output, and all pages will +# contain a <link> tag referring to it. The value of this option must be the +# base URL from which the finished HTML is served. +#html_use_opensearch = '' + +# This is the file name suffix for HTML files (e.g. ".xhtml"). +#html_file_suffix = None + +# Output file base name for HTML help builder. +htmlhelp_basename = 'ApacheQpidProtondoc' + + +# -- Options for LaTeX output -------------------------------------------------- + +latex_elements = { +# The paper size ('letterpaper' or 'a4paper'). +#'papersize': 'letterpaper', + +# The font size ('10pt', '11pt' or '12pt'). +#'pointsize': '10pt', + +# Additional stuff for the LaTeX preamble. +#'preamble': '', +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, author, documentclass [howto/manual]). +latex_documents = [ + ('index', 'ApacheQpidProton.tex', u'Apache Qpid Proton Documentation', + u'The Apache Qpid Community', 'manual'), +] + +# The name of an image file (relative to this directory) to place at the top of +# the title page. +#latex_logo = None + +# For "manual" documents, if this is true, then toplevel headings are parts, +# not chapters. +#latex_use_parts = False + +# If true, show page references after internal links. +#latex_show_pagerefs = False + +# If true, show URL addresses after external links. +#latex_show_urls = False + +# Documents to append as an appendix to all manuals. +#latex_appendices = [] + +# If false, no module index is generated. +#latex_domain_indices = True + + +# -- Options for manual page output -------------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + ('index', 'apacheqpidproton', u'Apache Qpid Proton Documentation', + [u'The Apache Qpid Community'], 1) +] + +# If true, show URL addresses after external links. +#man_show_urls = False + + +# -- Options for Texinfo output ------------------------------------------------ + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + ('index', 'ApacheQpidProton', u'Apache Qpid Proton Documentation', + u'The Apache Qpid Community', 'ApacheQpidProton', 'One line description of project.', + 'Miscellaneous'), +] + +# Documents to append as an appendix to all manuals. +#texinfo_appendices = [] + +# If false, no module index is generated. +#texinfo_domain_indices = True + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#texinfo_show_urls = 'footnote' http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/index.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/index.rst b/proton-c/bindings/python/docs/index.rst new file mode 100644 index 0000000..927762b --- /dev/null +++ b/proton-c/bindings/python/docs/index.rst @@ -0,0 +1,11 @@ +Apache Qpid Proton: python documentation +======================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + tutorial + overview + http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/make.bat ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/make.bat b/proton-c/bindings/python/docs/make.bat deleted file mode 100644 index e3c7209..0000000 --- a/proton-c/bindings/python/docs/make.bat +++ /dev/null @@ -1,190 +0,0 @@ -@ECHO OFF - -REM Command file for Sphinx documentation - -if "%SPHINXBUILD%" == "" ( - set SPHINXBUILD=sphinx-build -) -set BUILDDIR=build -set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% source -set I18NSPHINXOPTS=%SPHINXOPTS% source -if NOT "%PAPER%" == "" ( - set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% - set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS% -) - -if "%1" == "" goto help - -if "%1" == "help" ( - :help - echo.Please use `make ^<target^>` where ^<target^> is one of - echo. html to make standalone HTML files - echo. dirhtml to make HTML files named index.html in directories - echo. singlehtml to make a single large HTML file - echo. pickle to make pickle files - echo. json to make JSON files - echo. htmlhelp to make HTML files and a HTML help project - echo. qthelp to make HTML files and a qthelp project - echo. devhelp to make HTML files and a Devhelp project - echo. epub to make an epub - echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter - echo. text to make text files - echo. man to make manual pages - echo. texinfo to make Texinfo files - echo. gettext to make PO message catalogs - echo. changes to make an overview over all changed/added/deprecated items - echo. linkcheck to check all external links for integrity - echo. doctest to run all doctests embedded in the documentation if enabled - goto end -) - -if "%1" == "clean" ( - for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i - del /q /s %BUILDDIR%\* - goto end -) - -if "%1" == "html" ( - %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/html. - goto end -) - -if "%1" == "dirhtml" ( - %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. - goto end -) - -if "%1" == "singlehtml" ( - %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. - goto end -) - -if "%1" == "pickle" ( - %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the pickle files. - goto end -) - -if "%1" == "json" ( - %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the JSON files. - goto end -) - -if "%1" == "htmlhelp" ( - %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run HTML Help Workshop with the ^ -.hhp project file in %BUILDDIR%/htmlhelp. - goto end -) - -if "%1" == "qthelp" ( - %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run "qcollectiongenerator" with the ^ -.qhcp project file in %BUILDDIR%/qthelp, like this: - echo.^> qcollectiongenerator %BUILDDIR%\qthelp\ApacheQpidProton.qhcp - echo.To view the help file: - echo.^> assistant -collectionFile %BUILDDIR%\qthelp\ApacheQpidProton.ghc - goto end -) - -if "%1" == "devhelp" ( - %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. - goto end -) - -if "%1" == "epub" ( - %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The epub file is in %BUILDDIR%/epub. - goto end -) - -if "%1" == "latex" ( - %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. - goto end -) - -if "%1" == "text" ( - %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The text files are in %BUILDDIR%/text. - goto end -) - -if "%1" == "man" ( - %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The manual pages are in %BUILDDIR%/man. - goto end -) - -if "%1" == "texinfo" ( - %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo. - goto end -) - -if "%1" == "gettext" ( - %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The message catalogs are in %BUILDDIR%/locale. - goto end -) - -if "%1" == "changes" ( - %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes - if errorlevel 1 exit /b 1 - echo. - echo.The overview file is in %BUILDDIR%/changes. - goto end -) - -if "%1" == "linkcheck" ( - %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck - if errorlevel 1 exit /b 1 - echo. - echo.Link check complete; look for any errors in the above output ^ -or in %BUILDDIR%/linkcheck/output.txt. - goto end -) - -if "%1" == "doctest" ( - %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest - if errorlevel 1 exit /b 1 - echo. - echo.Testing of doctests in the sources finished, look at the ^ -results in %BUILDDIR%/doctest/output.txt. - goto end -) - -:end http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/overview.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/overview.rst b/proton-c/bindings/python/docs/overview.rst new file mode 100644 index 0000000..f82deb2 --- /dev/null +++ b/proton-c/bindings/python/docs/overview.rst @@ -0,0 +1,160 @@ +############ +API Overview +############ + +========================= +An overview of the model +========================= + +Messages are transferred between connected peers over 'links'. At the +sending peer the link is called a sender. At the receiving peer it is +called a receiver. Messages are sent by senders and received by +receivers. Links may have named 'source' and 'target' addresses (for +example to identify the queue from which message were to be received +or to which they were to be sent). + +Links are established over sessions. Sessions are established over +connections. Connections are (generally) established between two +uniquely identified containers. Though a connection can have multiple +sessions, often this is not needed. The container API allows you to +ignore sessions unless you actually require them. + +The sending of a message over a link is called a delivery. The message +is the content sent, including all meta-data such as headers and +annotations. The delivery is the protocol exchange associated with the +transfer of that content. + +To indicate that a delivery is complete, either the sender or the +receiver 'settles' it. When the other side learns that it has been +settled, they will no longer communicate about that delivery. The +receiver can also indicate whether they accept or reject the +message. + +Three different delivery levels or 'guarantees' can be achieved: +at-most-once, at-least-once or exactly-once. See +:ref:`delivery-guarantees` for more detail. + +======================================================= +A summary of the most commonly used classes and members +======================================================= + +A brief summary of some of the key classes follows. + +The :py:class:`~proton.reactor.Container` class is a convenient entry +point into the API, allowing connections and links to be +established. Applications are structured as one or more event +handlers. Handlers can be set at Container, Connection, or Link +scope. Messages are sent by establishing an approprate sender and +invoking its :py:meth:`~proton.Sender.send()` method. This is +typically done when the sender is sendable, a condition indicated by +the :py:meth:`~proton.handlers.MessagingHandler.on_sendable()` event, to +avoid execessive build up of messages. Messages can be received by +establishing an appropriate receiver and handling the +:py:meth:`~proton.handlers.MessagingHandler.on_message()` event. + +.. autoclass:: proton.reactor.Container + :show-inheritance: proton.reactor.Reactor + :members: connect, create_receiver, create_sender, run, schedule + :undoc-members: + + .. py:attribute:: container_id + + The identifier used to identify this container in any + connections it establishes. Container names should be + unique. By default a UUID will be used. + + The :py:meth:`~proton.reactor.Container.connect()` method returns + an instance of :py:class:`~proton.Connection`, the + :py:meth:`~proton.reactor.Container.create_receiver()` method + returns an instance of :py:class:`~proton.Receiver` and the + :py:meth:`~proton.reactor.Container.create_sender()` method + returns an instance of :py:class:`~proton.Sender`. + +.. autoclass:: proton.Connection + :members: open, close, state, session, hostname, container, + remote_container, remote_desired_capabilities, remote_hostname, remote_offered_capabilities , remote_properties + :undoc-members: + +.. autoclass:: proton.Receiver + :show-inheritance: proton.Link + :members: flow, recv, drain, draining + :undoc-members: + +.. autoclass:: proton.Sender + :show-inheritance: proton.Link + :members: offered, send + :undoc-members: + +.. autoclass:: proton.Link + :members: name, state, is_sender, is_receiver, + credit, queued, session, connection, + source, target, remote_source, remote_target + :undoc-members: + + The :py:meth:`~proton.Link.source()`, + :py:meth:`~proton.Link.target()`, + :py:meth:`~proton.Link.remote_source()` and + :py:meth:`~proton.Link.remote_target()` methods all return an + instance of :py:class:`~proton.Terminus`. + + +.. autoclass:: proton.Delivery + :members: update, settle, settled, remote_state, local_state, partial, readable, writable, + link, session, connection + :undoc-members: + +.. autoclass:: proton.handlers.MessagingHandler + :members: on_start, on_reactor_init, + on_message, + on_accepted, + on_rejected, + on_settled, + on_sendable, + on_connection_error, + on_link_error, + on_session_error, + on_disconnected, + accept, reject, release, settle + :undoc-members: + +.. autoclass:: proton.Event + :members: delivery, link, receiver, sender, session, connection, reactor, context + :undoc-members: + +.. autoclass:: proton.Message + :members: address, id, priority, subject, ttl, reply_to, correlation_id, durable, user_id, + content_type, content_encoding, creation_time, expiry_time, delivery_count, first_acquirer, + group_id, group_sequence, reply_to_group_id, + send, recv, encode, decode + :undoc-members: + +.. autoclass:: proton.Terminus + :members: address, dynamic, properties, capabilities, filter + :undoc-members: + +.. _delivery-guarantees: + +=================== +Delivery guarantees +=================== + +For at-most-once, the sender settles the message as soon as it sends +it. If the connection is lost before the message is received by the +receiver, the message will not be delivered. + +For at-least-once, the receiver accepts and settles the message on +receipt. If the connection is lost before the sender is informed of +the settlement, then the delivery is considered in-doubt and should be +retried. This will ensure it eventually gets delivered (provided of +course the connection and link can be reestablished). It may mean that +it is delivered multiple times though. + +Finally, for exactly-once, the receiver accepts the message but +doesn't settle it. The sender settles once it is aware that the +receiver accepted it. In this way the receiver retains knowledge of an +accepted message until it is sure the sender knows it has been +accepted. If the connection is lost before settlement, the receiver +informs the sender of all the unsettled deliveries it knows about, and +from this the sender can deduce which need to be redelivered. The +sender likewise informs the receiver which deliveries it knows about, +from which the receiver can deduce which have already been settled. http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/source/conf.py ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/source/conf.py b/proton-c/bindings/python/docs/source/conf.py deleted file mode 100644 index 206ef89..0000000 --- a/proton-c/bindings/python/docs/source/conf.py +++ /dev/null @@ -1,242 +0,0 @@ -# -*- coding: utf-8 -*- -# -# Apache Qpid Proton documentation build configuration file, created by -# sphinx-quickstart on Mon Feb 16 14:13:09 2015. -# -# This file is execfile()d with the current directory set to its containing dir. -# -# Note that not all possible configuration values are present in this -# autogenerated file. -# -# All configuration values have a default; values that are commented out -# serve to show the default. - -import sys, os - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -#sys.path.insert(0, os.path.abspath('.')) - -# -- General configuration ----------------------------------------------------- - -# If your documentation needs a minimal Sphinx version, state it here. -#needs_sphinx = '1.0' - -# Add any Sphinx extension module names here, as strings. They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo'] - -# Add any paths that contain templates here, relative to this directory. -#templates_path = ['_templates'] - -# The suffix of source filenames. -source_suffix = '.rst' - -# The encoding of source files. -#source_encoding = 'utf-8-sig' - -# The master toctree document. -master_doc = 'index' - -# General information about the project. -project = u'Apache Qpid Proton' -copyright = u'2015, Apache Qpid' - -# The version info for the project you're documenting, acts as replacement for -# |version| and |release|, also used in various other places throughout the -# built documents. -# -# The short X.Y version. -version = '0.9' -# The full version, including alpha/beta/rc tags. -release = '0.9' - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -#language = None - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -#today = '' -# Else, today_fmt is used as the format for a strftime call. -#today_fmt = '%B %d, %Y' - -# List of patterns, relative to source directory, that match files and -# directories to ignore when looking for source files. -exclude_patterns = [] - -# The reST default role (used for this markup: `text`) to use for all documents. -#default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -#add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -#add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -#show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'sphinx' - -# A list of ignored prefixes for module index sorting. -#modindex_common_prefix = [] - - -# -- Options for HTML output --------------------------------------------------- - -# The theme to use for HTML and HTML Help pages. See the documentation for -# a list of builtin themes. -html_theme = 'sphinxdoc' - -# Theme options are theme-specific and customize the look and feel of a theme -# further. For a list of options available for each theme, see the -# documentation. -#html_theme_options = {} - -# Add any paths that contain custom themes here, relative to this directory. -#html_theme_path = [] - -# The name for this set of Sphinx documents. If None, it defaults to -# "<project> v<release> documentation". -#html_title = None - -# A shorter title for the navigation bar. Default is the same as html_title. -#html_short_title = None - -# The name of an image file (relative to this directory) to place at the top -# of the sidebar. -#html_logo = None - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -#html_favicon = None - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -#html_static_path = ['_static'] - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -#html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -#html_use_smartypants = True - -# Custom sidebar templates, maps document names to template names. -#html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -#html_additional_pages = {} - -# If false, no module index is generated. -#html_domain_indices = True - -# If false, no index is generated. -#html_use_index = True - -# If true, the index is split into individual pages for each letter. -#html_split_index = False - -# If true, links to the reST sources are added to the pages. -#html_show_sourcelink = True - -# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. -#html_show_sphinx = True - -# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. -#html_show_copyright = True - -# If true, an OpenSearch description file will be output, and all pages will -# contain a <link> tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -#html_use_opensearch = '' - -# This is the file name suffix for HTML files (e.g. ".xhtml"). -#html_file_suffix = None - -# Output file base name for HTML help builder. -htmlhelp_basename = 'ApacheQpidProtondoc' - - -# -- Options for LaTeX output -------------------------------------------------- - -latex_elements = { -# The paper size ('letterpaper' or 'a4paper'). -#'papersize': 'letterpaper', - -# The font size ('10pt', '11pt' or '12pt'). -#'pointsize': '10pt', - -# Additional stuff for the LaTeX preamble. -#'preamble': '', -} - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, documentclass [howto/manual]). -latex_documents = [ - ('index', 'ApacheQpidProton.tex', u'Apache Qpid Proton Documentation', - u'The Apache Qpid Community', 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -#latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -#latex_use_parts = False - -# If true, show page references after internal links. -#latex_show_pagerefs = False - -# If true, show URL addresses after external links. -#latex_show_urls = False - -# Documents to append as an appendix to all manuals. -#latex_appendices = [] - -# If false, no module index is generated. -#latex_domain_indices = True - - -# -- Options for manual page output -------------------------------------------- - -# One entry per manual page. List of tuples -# (source start file, name, description, authors, manual section). -man_pages = [ - ('index', 'apacheqpidproton', u'Apache Qpid Proton Documentation', - [u'The Apache Qpid Community'], 1) -] - -# If true, show URL addresses after external links. -#man_show_urls = False - - -# -- Options for Texinfo output ------------------------------------------------ - -# Grouping the document tree into Texinfo files. List of tuples -# (source start file, target name, title, author, -# dir menu entry, description, category) -texinfo_documents = [ - ('index', 'ApacheQpidProton', u'Apache Qpid Proton Documentation', - u'The Apache Qpid Community', 'ApacheQpidProton', 'One line description of project.', - 'Miscellaneous'), -] - -# Documents to append as an appendix to all manuals. -#texinfo_appendices = [] - -# If false, no module index is generated. -#texinfo_domain_indices = True - -# How to display URL addresses: 'footnote', 'no', or 'inline'. -#texinfo_show_urls = 'footnote' http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/source/index.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/source/index.rst b/proton-c/bindings/python/docs/source/index.rst deleted file mode 100644 index 2e78cd3..0000000 --- a/proton-c/bindings/python/docs/source/index.rst +++ /dev/null @@ -1,24 +0,0 @@ -.. Apache Qpid Proton documentation master file, created by - sphinx-quickstart on Mon Feb 16 14:13:09 2015. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Welcome to Apache Qpid Proton's documentation! -============================================== - -Contents: - -.. toctree:: - :maxdepth: 2 - - tutorial - overview - reference - -Indices and tables -================== - -* :ref:`genindex` -* :ref:`modindex` -* :ref:`search` - http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/source/overview.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/source/overview.rst b/proton-c/bindings/python/docs/source/overview.rst deleted file mode 100644 index d589c0b..0000000 --- a/proton-c/bindings/python/docs/source/overview.rst +++ /dev/null @@ -1,161 +0,0 @@ -############ -API Overview -############ - -========================= -An overview of the model -========================= - -Messages are transferred between connected peers over 'links'. At the -sending peer the link is called a sender. At the receiving peer it is -called a receiver. Messages are sent by senders and received by -receivers. Links may have named 'source' and 'target' addresses (for -example to identify the queue from which message were to be received -or to which they were to be sent). - -Links are established over sessions. Sessions are established over -connections. Connections are (generally) established between two -uniquely identified containers. Though a connection can have multiple -sessions, often this is not needed. The container API allows you to -ignore sessions unless you actually require them. - -The sending of a message over a link is called a delivery. The message -is the content sent, including all meta-data such as headers and -annotations. The delivery is the protocol exchange associated with the -transfer of that content. - -To indicate that a delivery is complete, either the sender or the -receiver 'settles' it. When the other side learns that it has been -settled, they will no longer communicate about that delivery. The -receiver can also indicate whether they accept or reject the -message. - -Three different delivery levels or 'guarantees' can be achieved: -at-most-once, at-least-once or exactly-once. See -:ref:`delivery-guarantees` for more detail. - -======================================================= -A summary of the most commonly used classes and members -======================================================= - -A brief summary of some of the key classes follows. A more complete -reference is available in :doc:`reference`. - -The :py:class:`~proton.reactor.Container` class is a convenient entry -point into the API, allowing connections and links to be -established. Applications are structured as one or more event -handlers. Handlers can be set at Container, Connection, or Link -scope. Messages are sent by establishing an approprate sender and -invoking its :py:meth:`~proton.Sender.send()` method. This is -typically done when the sender is sendable, a condition indicated by -the :py:meth:`~proton.handlers.MessagingHandler.on_sendable()` event, to -avoid execessive build up of messages. Messages can be received by -establishing an appropriate receiver and handling the -:py:meth:`~proton.handlers.MessagingHandler.on_message()` event. - -.. autoclass:: proton.reactor.Container - :show-inheritance: proton.reactor.Reactor - :members: connect, create_receiver, create_sender, run, schedule - :undoc-members: - - .. py:attribute:: container_id - - The identifier used to identify this container in any - connections it establishes. Container names should be - unique. By default a UUID will be used. - - The :py:meth:`~proton.reactor.Container.connect()` method returns - an instance of :py:class:`~proton.Connection`, the - :py:meth:`~proton.reactor.Container.create_receiver()` method - returns an instance of :py:class:`~proton.Receiver` and the - :py:meth:`~proton.reactor.Container.create_sender()` method - returns an instance of :py:class:`~proton.Sender`. - -.. autoclass:: proton.Connection - :members: open, close, state, session, hostname, container, - remote_container, remote_desired_capabilities, remote_hostname, remote_offered_capabilities , remote_properties - :undoc-members: - -.. autoclass:: proton.Receiver - :show-inheritance: proton.Link - :members: flow, recv, drain, draining - :undoc-members: - -.. autoclass:: proton.Sender - :show-inheritance: proton.Link - :members: offered, send - :undoc-members: - -.. autoclass:: proton.Link - :members: name, state, is_sender, is_receiver, - credit, queued, session, connection, - source, target, remote_source, remote_target - :undoc-members: - - The :py:meth:`~proton.Link.source()`, - :py:meth:`~proton.Link.target()`, - :py:meth:`~proton.Link.remote_source()` and - :py:meth:`~proton.Link.remote_target()` methods all return an - instance of :py:class:`~proton.Terminus`. - - -.. autoclass:: proton.Delivery - :members: update, settle, settled, remote_state, local_state, partial, readable, writable, - link, session, connection - :undoc-members: - -.. autoclass:: proton.handlers.MessagingHandler - :members: on_start, on_reactor_init, - on_message, - on_accepted, - on_rejected, - on_settled, - on_sendable, - on_connection_error, - on_link_error, - on_session_error, - on_disconnected, - accept, reject, release, settle - :undoc-members: - -.. autoclass:: proton.Event - :members: delivery, link, receiver, sender, session, connection, reactor, context - :undoc-members: - -.. autoclass:: proton.Message - :members: address, id, priority, subject, ttl, reply_to, correlation_id, durable, user_id, - content_type, content_encoding, creation_time, expiry_time, delivery_count, first_acquirer, - group_id, group_sequence, reply_to_group_id, - send, recv, encode, decode - :undoc-members: - -.. autoclass:: proton.Terminus - :members: address, dynamic, properties, capabilities, filter - :undoc-members: - -.. _delivery-guarantees: - -=================== -Delivery guarantees -=================== - -For at-most-once, the sender settles the message as soon as it sends -it. If the connection is lost before the message is received by the -receiver, the message will not be delivered. - -For at-least-once, the receiver accepts and settles the message on -receipt. If the connection is lost before the sender is informed of -the settlement, then the delivery is considered in-doubt and should be -retried. This will ensure it eventually gets delivered (provided of -course the connection and link can be reestablished). It may mean that -it is delivered multiple times though. - -Finally, for exactly-once, the receiver accepts the message but -doesn't settle it. The sender settles once it is aware that the -receiver accepted it. In this way the receiver retains knowledge of an -accepted message until it is sure the sender knows it has been -accepted. If the connection is lost before settlement, the receiver -informs the sender of all the unsettled deliveries it knows about, and -from this the sender can deduce which need to be redelivered. The -sender likewise informs the receiver which deliveries it knows about, -from which the receiver can deduce which have already been settled. http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/source/reference.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/source/reference.rst b/proton-c/bindings/python/docs/source/reference.rst deleted file mode 100644 index 06f6b30..0000000 --- a/proton-c/bindings/python/docs/source/reference.rst +++ /dev/null @@ -1,44 +0,0 @@ -############# -API Reference -############# - -proton Package -============== - -:mod:`proton` Package ---------------------- - -.. automodule:: proton.__init__ - :noindex: - :members: - :undoc-members: - :show-inheritance: - :exclude-members: Messenger, Url - -:mod:`reactor` Module ---------------------- - -.. automodule:: proton.reactor - :noindex: - :members: - :undoc-members: - :show-inheritance: - -:mod:`handlers` Module ----------------------- - -.. automodule:: proton.handlers - :noindex: - :members: - :undoc-members: - :show-inheritance: - -:mod:`utils` Module -------------------- - -.. automodule:: proton.utils - :noindex: - :members: - :undoc-members: - :show-inheritance: - http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/source/tutorial.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/source/tutorial.rst b/proton-c/bindings/python/docs/source/tutorial.rst deleted file mode 100644 index 6f7550c..0000000 --- a/proton-c/bindings/python/docs/source/tutorial.rst +++ /dev/null @@ -1,301 +0,0 @@ -######## -Tutorial -######## - -============ -Hello World! -============ - -Tradition dictates that we start with hello world! However rather than -simply striving for the shortest program possible, we'll aim for a -more illustrative example while still restricting the functionality to -sending and receiving a single message. - -.. literalinclude:: ../../../../../examples/python/helloworld.py - :lines: 21- - :linenos: - -You can see the import of :py:class:`~proton.reactor.Container` from ``proton.reactor`` on the -second line. This is a class that makes programming with proton a -little easier for the common cases. It includes within it an event -loop, and programs written using this utility are generally structured -to react to various events. This reactive style is particularly suited -to messaging applications. - -To be notified of a particular event, you define a class with the -appropriately name method on it. That method is then called by the -event loop when the event occurs. - -We define a class here, ``HelloWorld``, which handles the key events of -interest in sending and receiving a message. - -The ``on_start()`` method is called when the event loop first -starts. We handle that by establishing our connection (line 12), a -sender over which to send the message (line 13) and a receiver over -which to receive it back again (line 14). - -The ``on_sendable()`` method is called when message can be transferred -over the associated sender link to the remote peer. We send out our -``Hello World!`` message (line 17), then close the sender (line 18) as -we only want to send one message. The closing of the sender will -prevent further calls to ``on_sendable()``. - -The ``on_message()`` method is called when a message is -received. Within that we simply print the body of the message (line -21) and then close the connection (line 22). - -Now that we have defined the logic for handling these events, we -create an instance of a :py:class:`~proton.reactor.Container`, pass it -our handler and then enter the event loop by calling -:py:meth:`~proton.reactor.Container.run()`. At this point control -passes to the container instance, which will make the appropriate -callbacks to any defined handlers. - -To run the example you will need to have a broker (or similar) -accepting connections on that url either with a queue (or topic) -matching the given address or else configured to create such a queue -(or topic) dynamically. There is a simple broker.py script included -alongside the examples that can be used for this purpose if -desired. (It is also written using the API described here, and as such -gives an example of a slightly more involved application). - -==================== -Hello World, Direct! -==================== - -Though often used in conjunction with a broker, AMQP does not -*require* this. It also allows senders and receivers can communicate -directly if desired. - -Let's modify our example to demonstrate this. - -.. literalinclude:: ../../../../../examples/python/helloworld_direct.py - :lines: 21- - :emphasize-lines: 11,21-22,24-25 - :linenos: - -The first difference, on line 11, is that rather than creating a -receiver on the same connection as our sender, we listen for incoming -connections by invoking the -:py:meth:`~proton.reactor.Container.listen()` method on the -container. - -As we only need then to initiate one link, the sender, we can do that -by passing in a url rather than an existing connection, and the -connection will also be automatically established for us. - -We send the message in response to the ``on_sendable()`` callback and -print the message out in response to the ``on_message()`` callback -exactly as before. - -However we also handle two new events. We now close the connection -from the senders side once the message has been accepted (line -22). The acceptance of the message is an indication of successful -transfer to the peer. We are notified of that event through the -``on_accepted()`` callback. Then, once the connection has been closed, -of which we are notified through the ``on_closed()`` callback, we stop -accepting incoming connections (line 25) at which point there is no -work to be done and the event loop exits, and the run() method will -return. - -So now we have our example working without a broker involved! - -============================= -Asynchronous Send and Receive -============================= - -Of course, these ``HelloWorld!`` examples are very artificial, -communicating as they do over a network connection but with the same -process. A more realistic example involves communication between -separate processes (which could indeed be running on completely -separate machines). - -Let's separate the sender from the receiver, and let's transfer more than -a single message between them. - -We'll start with a simple sender. - -.. literalinclude:: ../../../../../examples/python/simple_send.py - :lines: 21- - :linenos: - -As with the previous example, we define the application logic in a -class that handles various events. As before, we use the -``on_start()`` event to establish our sender link over which we will -transfer messages and the ``on_sendable()`` event to know when we can -transfer our messages. - -Because we are transferring more than one message, we need to keep -track of how many we have sent. We'll use a ``sent`` member variable -for that. The ``total`` member variable will hold the number of -messages we want to send. - -AMQP defines a credit-based flow control mechanism. Flow control -allows the receiver to control how many messages it is prepared to -receive at a given time and thus prevents any component being -overwhelmed by the number of messages it is sent. - -In the ``on_sendable()`` callback, we check that our sender has credit -before sending messages. We also check that we haven't already sent -the required number of messages. - -The ``send()`` call on line 20 is of course asynchronous. When it -returns the message has not yet actually been transferred across the -network to the receiver. By handling the ``on_accepted()`` event, we -can get notified when the receiver has received and accepted the -message. In our example we use this event to track the confirmation of -the messages we have sent. We only close the connection and exit when -the receiver has received all the messages we wanted to send. - -If we are disconnected after a message is sent and before it has been -confirmed by the receiver, it is said to be ``in doubt``. We don't -know whether or not it was received. In this example, we will handle -that by resending any in-doubt messages. This is known as an -'at-least-once' guarantee, since each message should eventually be -received at least once, though a given message may be received more -than once (i.e. duplicates are possible). In the ``on_disconnected()`` -callback, we reset the sent count to reflect only those that have been -confirmed. The library will automatically try to reconnect for us, and -when our sender is sendable again, we can restart from the point we -know the receiver got to. - -Now let's look at the corresponding receiver: - -.. literalinclude:: ../../../../../examples/python/simple_recv.py - :lines: 21- - :linenos: - -Here we handle the ``on_start()`` by creating our receiver, much like -we did for the sender. We also handle the ``on_message()`` event for -received messages and print the message out as in the ``Hello World!`` -examples. However we add some logic to allow the receiver to wait for -a given number of messages, then to close the connection and exit. We -also add some logic to check for and ignore duplicates, using a simple -sequential id scheme. - -Again, though sending between these two examples requires some sort of -intermediary process (e.g. a broker), AMQP allows us to send messages -directly between two processes without this if we so wish. In that -case one or other of the processes needs to accept incoming socket -connections. Let's create a modified version of the receiving example -that does this: - -.. literalinclude:: ../../../../../examples/python/direct_recv.py - :lines: 21- - :emphasize-lines: 13,25 - :linenos: - -There are only two differences here. On line 13, instead of initiating -a link (and implicitly a connection), we listen for incoming -connections. On line 25, when we have received all the expected -messages, we then stop listening for incoming connections by closing -the acceptor object. - -You can use the original send example now to send to this receiver -directly. (Note: you will need to stop any broker that is listening on -the 5672 port, or else change the port used by specifying a different -address to each example via the -a command line switch). - -We could equally well modify the original sender to allow the original -receiver to connect to it. Again that just requires two modifications: - -.. literalinclude:: ../../../../../examples/python/direct_send.py - :lines: 21- - :emphasize-lines: 15,28 - :linenos: - -As with the modified receiver, instead of initiating establishment of -a link, we listen for incoming connections on line 15 and then on line -28, when we have received confirmation of all the messages we sent, we -can close the acceptor in order to exit. The symmetry in the -underlying AMQP that enables this is quite unique and elegant, and in -reflecting this the proton API provides a flexible toolkit for -implementing all sorts of interesting intermediaries (the broker.py -script provided as a simple broker for testing purposes provides an -example of this). - -To try this modified sender, run the original receiver against it. - -================ -Request/Response -================ - -A common pattern is to send a request message and expect a response -message in return. AMQP has special support for this pattern. Let's -have a look at a simple example. We'll start with the 'server', -i.e. the program that will process the request and send the -response. Note that we are still using a broker in this example. - -Our server will provide a very simple service: it will respond with -the body of the request converted to uppercase. - -.. literalinclude:: ../../../../../examples/python/server.py - :lines: 21- - :linenos: - -The code here is not too different from the simple receiver -example. When we receive a request however, we look at the -:py:attr:`~proton.Message.reply_to` address on the -:py:class:`~proton.Message` and create a sender for that over which to -send the response. We'll cache the senders incase we get further -requests with the same reply_to. - -Now let's create a simple client to test this service out. - -.. literalinclude:: ../../../../../examples/python/client.py - :lines: 21- - :linenos: - -As well as sending requests, we need to be able to get back the -responses. We create a receiver for that (see line 14), but we don't -specify an address, we set the dynamic option which tells the broker -we are connected to to create a temporary address over which we can -receive our responses. - -We need to use the address allocated by the broker as the reply_to -address of our requests, so we can't send them until the broker has -confirmed our receiving link has been set up (at which point we will -have our allocated address). To do that, we add an -``on_link_opened()`` method to our handler class, and if the link -associated with event is the receiver, we use that as the trigger to -send our first request. - -Again, we could avoid having any intermediary process here if we -wished. The following code implementas a server to which the client -above could connect directly without any need for a broker or similar. - -.. literalinclude:: ../../../../../examples/python/server_direct.py - :lines: 21- - :linenos: - -Though this requires some more extensive changes than the simple -sending and receiving examples, the essence of the program is still -the same. Here though, rather than the server establishing a link for -the response, it relies on the link that the client established, since -that now comes in directly to the server process. - -Miscellaneous -============= - -Many brokers offer the ability to consume messages based on a -'selector' that defines which messages are of interest based on -particular values of the headers. The following example shows how that -can be achieved: - -.. literalinclude:: ../../../../../examples/python/selected_recv.py - :lines: 21- - :emphasize-lines: 10 - :linenos: - -When creating the receiver, we specify a Selector object as an -option. The options argument can take a single object or a -list. Another option that is sometimes of interest when using a broker -is the ability to 'browse' the messages on a queue, rather than -consumig them. This is done in AMQP by specifying a distribution mode -of 'copy' (instead of 'move' which is the expected default for -queues). An example of that is shown next: - -.. literalinclude:: ../../../../../examples/python/queue_browser.py - :lines: 21- - :emphasize-lines: 10 - :linenos: http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/26a0622c/proton-c/bindings/python/docs/tutorial.rst ---------------------------------------------------------------------- diff --git a/proton-c/bindings/python/docs/tutorial.rst b/proton-c/bindings/python/docs/tutorial.rst new file mode 100644 index 0000000..6f7550c --- /dev/null +++ b/proton-c/bindings/python/docs/tutorial.rst @@ -0,0 +1,301 @@ +######## +Tutorial +######## + +============ +Hello World! +============ + +Tradition dictates that we start with hello world! However rather than +simply striving for the shortest program possible, we'll aim for a +more illustrative example while still restricting the functionality to +sending and receiving a single message. + +.. literalinclude:: ../../../../../examples/python/helloworld.py + :lines: 21- + :linenos: + +You can see the import of :py:class:`~proton.reactor.Container` from ``proton.reactor`` on the +second line. This is a class that makes programming with proton a +little easier for the common cases. It includes within it an event +loop, and programs written using this utility are generally structured +to react to various events. This reactive style is particularly suited +to messaging applications. + +To be notified of a particular event, you define a class with the +appropriately name method on it. That method is then called by the +event loop when the event occurs. + +We define a class here, ``HelloWorld``, which handles the key events of +interest in sending and receiving a message. + +The ``on_start()`` method is called when the event loop first +starts. We handle that by establishing our connection (line 12), a +sender over which to send the message (line 13) and a receiver over +which to receive it back again (line 14). + +The ``on_sendable()`` method is called when message can be transferred +over the associated sender link to the remote peer. We send out our +``Hello World!`` message (line 17), then close the sender (line 18) as +we only want to send one message. The closing of the sender will +prevent further calls to ``on_sendable()``. + +The ``on_message()`` method is called when a message is +received. Within that we simply print the body of the message (line +21) and then close the connection (line 22). + +Now that we have defined the logic for handling these events, we +create an instance of a :py:class:`~proton.reactor.Container`, pass it +our handler and then enter the event loop by calling +:py:meth:`~proton.reactor.Container.run()`. At this point control +passes to the container instance, which will make the appropriate +callbacks to any defined handlers. + +To run the example you will need to have a broker (or similar) +accepting connections on that url either with a queue (or topic) +matching the given address or else configured to create such a queue +(or topic) dynamically. There is a simple broker.py script included +alongside the examples that can be used for this purpose if +desired. (It is also written using the API described here, and as such +gives an example of a slightly more involved application). + +==================== +Hello World, Direct! +==================== + +Though often used in conjunction with a broker, AMQP does not +*require* this. It also allows senders and receivers can communicate +directly if desired. + +Let's modify our example to demonstrate this. + +.. literalinclude:: ../../../../../examples/python/helloworld_direct.py + :lines: 21- + :emphasize-lines: 11,21-22,24-25 + :linenos: + +The first difference, on line 11, is that rather than creating a +receiver on the same connection as our sender, we listen for incoming +connections by invoking the +:py:meth:`~proton.reactor.Container.listen()` method on the +container. + +As we only need then to initiate one link, the sender, we can do that +by passing in a url rather than an existing connection, and the +connection will also be automatically established for us. + +We send the message in response to the ``on_sendable()`` callback and +print the message out in response to the ``on_message()`` callback +exactly as before. + +However we also handle two new events. We now close the connection +from the senders side once the message has been accepted (line +22). The acceptance of the message is an indication of successful +transfer to the peer. We are notified of that event through the +``on_accepted()`` callback. Then, once the connection has been closed, +of which we are notified through the ``on_closed()`` callback, we stop +accepting incoming connections (line 25) at which point there is no +work to be done and the event loop exits, and the run() method will +return. + +So now we have our example working without a broker involved! + +============================= +Asynchronous Send and Receive +============================= + +Of course, these ``HelloWorld!`` examples are very artificial, +communicating as they do over a network connection but with the same +process. A more realistic example involves communication between +separate processes (which could indeed be running on completely +separate machines). + +Let's separate the sender from the receiver, and let's transfer more than +a single message between them. + +We'll start with a simple sender. + +.. literalinclude:: ../../../../../examples/python/simple_send.py + :lines: 21- + :linenos: + +As with the previous example, we define the application logic in a +class that handles various events. As before, we use the +``on_start()`` event to establish our sender link over which we will +transfer messages and the ``on_sendable()`` event to know when we can +transfer our messages. + +Because we are transferring more than one message, we need to keep +track of how many we have sent. We'll use a ``sent`` member variable +for that. The ``total`` member variable will hold the number of +messages we want to send. + +AMQP defines a credit-based flow control mechanism. Flow control +allows the receiver to control how many messages it is prepared to +receive at a given time and thus prevents any component being +overwhelmed by the number of messages it is sent. + +In the ``on_sendable()`` callback, we check that our sender has credit +before sending messages. We also check that we haven't already sent +the required number of messages. + +The ``send()`` call on line 20 is of course asynchronous. When it +returns the message has not yet actually been transferred across the +network to the receiver. By handling the ``on_accepted()`` event, we +can get notified when the receiver has received and accepted the +message. In our example we use this event to track the confirmation of +the messages we have sent. We only close the connection and exit when +the receiver has received all the messages we wanted to send. + +If we are disconnected after a message is sent and before it has been +confirmed by the receiver, it is said to be ``in doubt``. We don't +know whether or not it was received. In this example, we will handle +that by resending any in-doubt messages. This is known as an +'at-least-once' guarantee, since each message should eventually be +received at least once, though a given message may be received more +than once (i.e. duplicates are possible). In the ``on_disconnected()`` +callback, we reset the sent count to reflect only those that have been +confirmed. The library will automatically try to reconnect for us, and +when our sender is sendable again, we can restart from the point we +know the receiver got to. + +Now let's look at the corresponding receiver: + +.. literalinclude:: ../../../../../examples/python/simple_recv.py + :lines: 21- + :linenos: + +Here we handle the ``on_start()`` by creating our receiver, much like +we did for the sender. We also handle the ``on_message()`` event for +received messages and print the message out as in the ``Hello World!`` +examples. However we add some logic to allow the receiver to wait for +a given number of messages, then to close the connection and exit. We +also add some logic to check for and ignore duplicates, using a simple +sequential id scheme. + +Again, though sending between these two examples requires some sort of +intermediary process (e.g. a broker), AMQP allows us to send messages +directly between two processes without this if we so wish. In that +case one or other of the processes needs to accept incoming socket +connections. Let's create a modified version of the receiving example +that does this: + +.. literalinclude:: ../../../../../examples/python/direct_recv.py + :lines: 21- + :emphasize-lines: 13,25 + :linenos: + +There are only two differences here. On line 13, instead of initiating +a link (and implicitly a connection), we listen for incoming +connections. On line 25, when we have received all the expected +messages, we then stop listening for incoming connections by closing +the acceptor object. + +You can use the original send example now to send to this receiver +directly. (Note: you will need to stop any broker that is listening on +the 5672 port, or else change the port used by specifying a different +address to each example via the -a command line switch). + +We could equally well modify the original sender to allow the original +receiver to connect to it. Again that just requires two modifications: + +.. literalinclude:: ../../../../../examples/python/direct_send.py + :lines: 21- + :emphasize-lines: 15,28 + :linenos: + +As with the modified receiver, instead of initiating establishment of +a link, we listen for incoming connections on line 15 and then on line +28, when we have received confirmation of all the messages we sent, we +can close the acceptor in order to exit. The symmetry in the +underlying AMQP that enables this is quite unique and elegant, and in +reflecting this the proton API provides a flexible toolkit for +implementing all sorts of interesting intermediaries (the broker.py +script provided as a simple broker for testing purposes provides an +example of this). + +To try this modified sender, run the original receiver against it. + +================ +Request/Response +================ + +A common pattern is to send a request message and expect a response +message in return. AMQP has special support for this pattern. Let's +have a look at a simple example. We'll start with the 'server', +i.e. the program that will process the request and send the +response. Note that we are still using a broker in this example. + +Our server will provide a very simple service: it will respond with +the body of the request converted to uppercase. + +.. literalinclude:: ../../../../../examples/python/server.py + :lines: 21- + :linenos: + +The code here is not too different from the simple receiver +example. When we receive a request however, we look at the +:py:attr:`~proton.Message.reply_to` address on the +:py:class:`~proton.Message` and create a sender for that over which to +send the response. We'll cache the senders incase we get further +requests with the same reply_to. + +Now let's create a simple client to test this service out. + +.. literalinclude:: ../../../../../examples/python/client.py + :lines: 21- + :linenos: + +As well as sending requests, we need to be able to get back the +responses. We create a receiver for that (see line 14), but we don't +specify an address, we set the dynamic option which tells the broker +we are connected to to create a temporary address over which we can +receive our responses. + +We need to use the address allocated by the broker as the reply_to +address of our requests, so we can't send them until the broker has +confirmed our receiving link has been set up (at which point we will +have our allocated address). To do that, we add an +``on_link_opened()`` method to our handler class, and if the link +associated with event is the receiver, we use that as the trigger to +send our first request. + +Again, we could avoid having any intermediary process here if we +wished. The following code implementas a server to which the client +above could connect directly without any need for a broker or similar. + +.. literalinclude:: ../../../../../examples/python/server_direct.py + :lines: 21- + :linenos: + +Though this requires some more extensive changes than the simple +sending and receiving examples, the essence of the program is still +the same. Here though, rather than the server establishing a link for +the response, it relies on the link that the client established, since +that now comes in directly to the server process. + +Miscellaneous +============= + +Many brokers offer the ability to consume messages based on a +'selector' that defines which messages are of interest based on +particular values of the headers. The following example shows how that +can be achieved: + +.. literalinclude:: ../../../../../examples/python/selected_recv.py + :lines: 21- + :emphasize-lines: 10 + :linenos: + +When creating the receiver, we specify a Selector object as an +option. The options argument can take a single object or a +list. Another option that is sometimes of interest when using a broker +is the ability to 'browse' the messages on a queue, rather than +consumig them. This is done in AMQP by specifying a distribution mode +of 'copy' (instead of 'move' which is the expected default for +queues). An example of that is shown next: + +.. literalinclude:: ../../../../../examples/python/queue_browser.py + :lines: 21- + :emphasize-lines: 10 + :linenos: --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
