qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From g...@apache.org
Subject qpid-proton git commit: NO-JIRA: integrate tutorial generation with the docs target from the main build
Date Wed, 27 May 2015 10:42:40 GMT
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 <gsim@redhat.com>
Authored: Wed May 27 11:38:53 2015 +0100
Committer: Gordon Sim <gsim@redhat.com>
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: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org


Mime
View raw message