qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acon...@apache.org
Subject [3/3] qpid-dispatch git commit: DISPATCH-399: Converted documentation to asciidoc format.
Date Thu, 23 Jun 2016 16:32:33 GMT
DISPATCH-399: Converted documentation to asciidoc format.

Converted .rst documentation files to asciidoc .adoc format.

asciidoc format is becoming more popular for documentation and has several
advantages over RST + sphinx.

- Mature, widely-used DocBook model without painful XML syntax
- Popular with doc writers (coming from docbook) and developers (e.g. github support)
- Fully-featured for serious documentation without needing extensions, unlike markdown.
- Standard support for multi-file documents and entity substitution
  - Sphinx has non-standard extensions for this, but they are not part of RST.
- Tools are simpler to use, need less configuration than sphinx.

Conversion from RST to asciidoc was straightforward (used pandoc). Most of the
work was tweaking the doc generators and CMake.


Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/4ba68bb8
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/4ba68bb8
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/4ba68bb8

Branch: refs/heads/master
Commit: 4ba68bb80951f0da70b7584a87fbf1f35ebf0880
Parents: b5ca35f
Author: Alan Conway <aconway@redhat.com>
Authored: Tue Jun 21 10:26:57 2016 -0400
Committer: Alan Conway <aconway@redhat.com>
Committed: Thu Jun 23 12:32:19 2016 -0400

----------------------------------------------------------------------
 doc/CMakeLists.txt                              | 244 ++++++++----------
 doc/README                                      |  91 +++----
 doc/api/CMakeLists.txt                          |  63 -----
 doc/api/README                                  |  33 ---
 doc/api/doxygen.in                              |  37 ---
 doc/asciidoc.conf.in                            |   5 +
 doc/book/addressing.adoc                        | 133 ++++++++++
 doc/book/addressing.rst                         | 127 ---------
 doc/book/amqp-mapping.adoc                      | 175 +++++++++++++
 doc/book/amqp-mapping.rst                       | 208 ---------------
 doc/book/auto_links.adoc                        | 257 +++++++++++++++++++
 doc/book/auto_links.rst                         | 251 ------------------
 doc/book/basic_usage.adoc                       | 203 +++++++++++++++
 doc/book/basic_usage.rst                        | 200 ---------------
 doc/book/book.adoc                              |  62 +++++
 doc/book/book.rst                               |  33 ---
 doc/book/client_compatibility.adoc              |  39 +++
 doc/book/client_compatibility.rst               |  45 ----
 doc/book/console.rst                            |  31 ---
 doc/book/console_installation.adoc              |  69 +++++
 doc/book/console_installation.rst               |  55 ----
 doc/book/console_operation.adoc                 |  89 +++++++
 doc/book/console_operation.rst                  |  64 -----
 doc/book/console_overview.adoc                  |  37 +++
 doc/book/console_overview.rst                   |  27 --
 doc/book/default_config.adoc                    |  35 +++
 doc/book/default_config.rst                     |  33 ---
 doc/book/introduction.adoc                      | 128 +++++++++
 doc/book/introduction.rst                       | 117 ---------
 doc/book/link_routing.adoc                      | 166 ++++++++++++
 doc/book/link_routing.rst                       | 162 ------------
 doc/book/schema_rst.py                          | 105 --------
 doc/book/schema_txt.py                          | 105 ++++++++
 doc/book/technical_details.rst                  |  32 ---
 doc/book/tools.adoc                             |  92 +++++++
 doc/book/tools.rst                              |  79 ------
 doc/book/using.rst                              |  30 ---
 doc/conf.py.in                                  |  47 ----
 doc/index.adoc                                  |  35 +++
 doc/index.rst                                   |  39 ---
 doc/man/help2rst.py                             |  62 -----
 doc/man/help2txt.py                             |  62 +++++
 doc/man/qdmanage.8.adoc                         | 140 ++++++++++
 doc/man/qdmanage.rst.in                         | 141 ----------
 doc/man/qdrouterd.8.adoc                        |  54 ++++
 doc/man/qdrouterd.conf.5.py                     | 212 +++++++++++++++
 doc/man/qdrouterd.rst.in                        |  49 ----
 doc/man/qdrouterd_conf_man.py                   | 210 ---------------
 doc/man/qdstat.8.adoc                           | 257 +++++++++++++++++++
 doc/man/qdstat.rst                              | 244 ------------------
 doc/notes/code-conventions.rst                  |  30 ---
 doc/notes/code-conventions.txt                  |  12 +
 doc/themes/bare/layout.html                     |  15 --
 doc/themes/bare/theme.conf                      |   8 -
 python/qpid_dispatch/management/qdrouter.json   |   2 +-
 .../management/schema_doc.py                    |  14 +-
 56 files changed, 2520 insertions(+), 2775 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
index 556b2cf..d140021 100644
--- a/doc/CMakeLists.txt
+++ b/doc/CMakeLists.txt
@@ -17,143 +17,123 @@
 ## under the License.
 ##
 
+# In old cmake (< 2.8) documentation is built by "make all" so set BUILD_DOC OFF
+# if you don't want that. For new cmake it is only built by "make doc"
+option(BUILD_DOCS "Generate documentation with 'make doc'" ON)
 
-# In recent versions of cmake the documentation is not built automatically, you need to
-# run "make doc", so you can leave this ON. In older (< 2.8) versions, documentation
-# is built by "make all" so you need to turn BUILD_DOCS OFF if you don't want that.
-option(BUILD_DOCS "Generate documentation" ON)
-
-if(BUILD_DOCS)
-
-  set(src ${CMAKE_CURRENT_SOURCE_DIR})
-  set(bin ${CMAKE_CURRENT_BINARY_DIR})
-  set(tools ${CMAKE_SOURCE_DIR}/tools)
-
-  if ("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" VERSION_LESS "2.8")
-    # OPTIONAL does not exist in install before 2.8 so always make docs and install
-    add_custom_target(doc ALL)
-  else()
-    set (OPTIONAL OPTIONAL)
-    add_custom_target(doc)
-    add_custom_target(docs DEPENDS doc) # some projects say "make doc" others "make docs" allow both.
-  endif()
+if ("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" VERSION_LESS "2.8")
+  # OPTIONAL does not exist in install before 2.8 so always make and install docs
+  set(DOC_TARGET ALL)
   macro(install_doc)
-    install(${ARGN} ${OPTIONAL})
-  endmacro()
-
-  find_package(Doxygen)
-  find_program(SPHINX_BUILD sphinx-build)
-
-  # Create an option to enable/disable a doc tool and check if the tool is present.
-  # If tool is present, option defaults to ON else OFF.
-  # If option is set ON by user and tool is not present, that is an error.
-  # If tool is not present and option is not set on just issue a status message.
-  #
-  macro(doc_tool tool use var what)
-    if(${var})
-      option(${use} "Generate ${what} with ${tool}" ON)
-    else(${var})
-      option(${use} "Generate ${what} with ${tool}" OFF)
-      if(${use})
-        message(SEND_ERROR "${use} enabled but ${tool} not found.")
-      else(${use})
-        message(STATUS "${tool} not found, not generating ${what}.")
-      endif(${use})
-    endif(${var})
-  endmacro()
-
-  doc_tool(sphinx-build USE_SPHINX SPHINX_BUILD "HTML and man page documentation")
-  doc_tool(doxygen USE_DOXYGEN DOXYGEN_FOUND "API documentation")
-  doc_tool(dot USE_DOT DOT "diagrams in API documentation (also requires doxygen)")
-
-  # Copy configuration and rst sources to build directory to generate book.
-  # Use configure_file to ensure we re-copy if the source changes.
-  configure_file(${src}/conf.py.in ${bin}/conf.py)
-  configure_file(${src}/man/qdmanage.rst.in ${bin}/man/qdmanage.rst)
-  configure_file(${src}/man/qdrouterd.rst.in ${bin}/man/qdrouterd.rst)
-  file(GLOB_RECURSE RST_SRC RELATIVE ${src} *.rst)
-  foreach(file ${RST_SRC})
-    configure_file(${src}/${file} ${bin}/${file} COPYONLY)
-  endforeach()
-
-  # Copy the images. Don't use configure_file since it truncates .png files at 1st ^Z character
-  file(GLOB_RECURSE PNG_SRC RELATIVE ${src} *.png)
-  foreach(file ${PNG_SRC})
-    EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src}/${file} ${bin}/${file})
-  endforeach()
-
-  # Generate files from management schema
-  set(schema, "${CMAKE_SOURCE_DIR}/python/qpid_router/management/qdrouterd.json")
-  set(py_management ${CMAKE_SOURCE_DIR}/python/qpid_dispatch_internal/management)
-  set(schema_gen_deps ${py_management}/schema_doc.py ${py_management}/schema.py ${schema})
-
-  macro(schema_gen output script)
-    add_custom_command(
-      OUTPUT ${output}
-      COMMAND ${RUN} -s ${script} 1> ${output}
-      DEPENDS ${script} ${schema_gen_deps}
-      )
-    list(APPEND SCHEMA_GEN ${output})
+    install(${ARGN})
   endmacro()
-
-  schema_gen(${bin}/book/schema.rst ${src}/book/schema_rst.py)
-  schema_gen(${bin}/man/qdrouterd.conf.rst ${src}/man/qdrouterd_conf_man.py)
-
-  add_custom_target(doc-schema DEPENDS ${SCHEMA_GEN})
-  add_dependencies(doc doc-schema)
-
-  # Generate rst text from --help output for man pages
-  macro(help2rst program path)
-    set(help ${bin}/man/${program}_help.rst)
-    list(APPEND HELP_GEN ${help})
-    add_custom_command (
-      OUTPUT ${help}
-      COMMAND ${RUN} -s ${src}/man/help2rst.py ${path}/${program} --help > ${help}
-      DEPENDS ${path}/${program} ${schema_doc} ${src}/man/help2rst.py
-      )
+else()
+  macro(install_doc)
+    install(${ARGN} OPTIONAL)
   endmacro()
+endif()
+
+# Popular locations
+set(src ${CMAKE_CURRENT_SOURCE_DIR})
+set(bin ${CMAKE_CURRENT_BINARY_DIR})
+set(tools ${CMAKE_SOURCE_DIR}/tools)
+set(schema ../python/qpid_dispatch/management/qdrouter.json)
+set(py_management ../python/qpid_dispatch_internal/management)
+set(schema_depends ${schema} ${py_management}/schema_doc.py ${py_management}/schema.py)
+
+## Always generate and install the asciidoc .adoc source files as a fallback.
+## They are readable even if we don't have the asciidoc tool to generate HTML.
+
+# Generate asciidoc fragments from management schema to incorporate in text
+macro(schema_gen script output)
+  add_custom_command(
+    OUTPUT ${output}
+    COMMAND ${RUN} -s ${script} 1> ${output}
+    DEPENDS ${script} ${schema_depends})
+  list(APPEND GENERATED_TXT "${output}")
+endmacro()
+
+schema_gen(${src}/book/schema_txt.py ${bin}/schema.adoc)
+schema_gen(${src}/man/qdrouterd.conf.5.py ${bin}/qdrouterd.conf.5.adoc)
+
+# Generate asciidoc .adoc from --help output for man pages
+macro(help2txt program)
+  get_filename_component(name ${program} NAME)
+  set(output ${bin}/${name}_help.adoc)
+  add_custom_command(
+    OUTPUT ${output}
+    COMMAND ${RUN} -s ${src}/man/help2txt.py ${program} --help 1> ${output}
+    DEPENDS ${program} ${schema_depends} ${src}/man/help2txt.py)
+  list(APPEND GENERATED_TXT "${output}")
+endmacro()
+
+help2txt(${CMAKE_BINARY_DIR}/router/qdrouterd)
+help2txt(${tools}/qdmanage)
+help2txt(${tools}/qdstat)
+
+add_custom_target(doc_gen ALL DEPENDS ${GENERATED_TXT})
+install(DIRECTORY ${src}/book/ DESTINATION ${QD_DOC_INSTALL_DIR})
+install(FILES ${bin}/schema.adoc DESTINATION ${QD_DOC_INSTALL_DIR})
 
-  help2rst(qdrouterd ${CMAKE_BINARY_DIR}/router)
-  help2rst(qdstat ${tools})
-  help2rst(qdmanage ${tools})
-
-  # Run sphinx to generate HTML and man pages
-  if(USE_SPHINX)
-    foreach(manpage qdmanage.8 qdrouterd.8 qdrouterd.conf.5 qdstat.8)
-      list(APPEND MAN_PAGES ${bin}/man/${manpage})
-      string(REGEX MATCH "[0-9]*$" section  ${manpage})
-      install_doc(FILES ${bin}/man/${manpage}
-        DESTINATION ${CMAKE_INSTALL_PREFIX}/${MAN_INSTALL_DIR}/man${section})
+if(BUILD_DOCS)
+  find_program(ASCIIDOC_EXE asciidoc DOC "Generate HTML documentation")
+  if (ASCIIDOC_EXE)
+    configure_file(${src}/asciidoc.conf.in ${bin}/asciidoc.conf)
+
+    # Copy the book dir images for HTML viewing in the build directory.
+    # Don't use configure_file since it truncates .png files at 1st ^Z character
+    EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy_directory ${src}/book/ ${bin})
+
+    # Generate HTML
+    file(GLOB_RECURSE ADOC_SRC *.adoc)
+    foreach(source index book/book man/qdmanage.8 man/qdrouterd.8 man/qdstat.8 ${bin}/qdrouterd.conf.5)
+      get_filename_component(name ${source} NAME)
+      set(output ${bin}/${name}.html)
+      add_custom_command(
+        OUTPUT ${output}
+        COMMAND ${ASCIIDOC_EXE} -b xhtml11 --conf-file=${bin}/asciidoc.conf -o ${output} ${source}.adoc
+        DEPENDS ${source}.adoc ${GENERATED_TXT} ${ADOC_SRC}
+        WORKING_DIRECTORY ${src} # Book include links assume we are in source dir.
+        )
+      list(APPEND DOC_DEPENDS ${output})
+      install_doc(FILES ${output} DESTINATION ${QD_DOC_INSTALL_DIR})
     endforeach()
 
-    set(SPHINX_OUTPUT ${bin}/html/index.html ${bin}/singlehtml/book/book.html ${MAN_PAGES})
-
-    set(html_raw_options -D html_theme=bare -D html_add_permalinks=".")
-    add_custom_command(
-      OUTPUT ${SPHINX_OUTPUT}
-      # html/ contains plain HTML suitable for embedding in the Qpid website.
-      COMMAND ${SPHINX_BUILD} -d ${bin}/doctrees -b html ${html_raw_options} ${bin} ${bin}/html
-      # dochtml/ is a self-contained site with searching, navigation etc. installed with the docs.
-      COMMAND ${SPHINX_BUILD} -d ${bin}/doctrees -b html ${bin} ${bin}/dochtml
-      # man/ contains Unix man pages.
-      COMMAND ${SPHINX_BUILD} -d ${bin}/doctrees -b man  ${bin} ${bin}/man
-      # singlehtml is a single HTML page
-      COMMAND ${SPHINX_BUILD} -d ${bin}/doctrees -b singlehtml ${bin} ${bin}/singlehtml
-      DEPENDS ${RST_SRC} ${HELP_GEN} ${SCHEMA_GEN}
-      )
-    add_custom_target(doc-sphinx DEPENDS ${SPHINX_OUTPUT})
-    add_dependencies(doc doc-sphinx)
-
-    install_doc(DIRECTORY ${bin}/dochtml/  DESTINATION ${QD_DOC_INSTALL_DIR}/html)
-
-    set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
-      ${bin}/html
-      ${bin}/singlehtml
-      ${bin}/dochtml)
-  endif(USE_SPHINX)
-
-  # Install rst documentation as baseline in case we have no generator
-  install(DIRECTORY ${bin}/ DESTINATION ${QD_DOC_INSTALL_DIR}/rst ${OPTIONAL} FILES_MATCHING PATTERN "*.rst")
-
-
+    find_program(A2X_EXE a2x DOC DOC "Generate Unix man pages")
+    if (A2X_EXE)
+      set(A2X_FLAGS --asciidoc-opts=--conf-file=${bin}/asciidoc.conf --asciidoc-opts=-v -D ${bin})
+
+      # Generate man pages.
+      foreach(source ${src}/man/qdmanage.8 ${src}/man/qdrouterd.8 ${src}/man/qdstat.8 ${bin}/qdrouterd.conf.5)
+        get_filename_component(name ${source} NAME)
+        string(REGEX MATCH "\\.([0-9])$" section ${source}) # Man section number
+        set(output ${bin}/${name})
+        add_custom_command(
+          OUTPUT ${output}
+          COMMAND ${A2X_EXE} ${A2X_FLAGS} -f manpage -D ${bin} ${source}.adoc
+          DEPENDS ${source}.adoc ${GENERATED_TXT})
+        list(APPEND DOC_DEPENDS ${output})
+        install_doc(FILES ${output} DESTINATION ${CMAKE_INSTALL_PREFIX}/${MAN_INSTALL_DIR}/man${section})
+      endforeach()
+
+      # Generate PDF if we have the latex tool
+      find_program(DBLATEX_EXE dblatex "Generate PDF documentation")
+      if (DBLATEX_EXE)
+        add_custom_command(
+          OUTPUT ${bin}/book.pdf
+          COMMAND ${A2X_EXE} ${A2X_FLAGS} -f pdf ${src}/book/book.adoc
+          DEPENDS ${src}/book/book.adoc ${GENERATED_TXT})
+        list(APPEND DOC_DEPENDS ${bin}/book.pdf)
+        install_doc(FILES ${bin}/book.pdf DESTINATION ${QD_DOC_INSTALL_DIR})
+      else(DBLATEX_EXE)
+        message("Not generating PDF user guide: dblatex not found")
+      endif(DBLATEX_EXE)
+    else(A2X_EXE)
+      message("Not generating Unix Man pages or PDF user guide: a2x not found")
+    endif(A2X_EXE)
+  else(ASCIIDOC_EXE)
+    message("No generated documentation: asciidoc not found")
+  endif(ASCIIDOC_EXE)
+
+  add_custom_target(doc ${DOC_TARGET} DEPENDS ${DOC_DEPENDS})
 endif(BUILD_DOCS)

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/README
----------------------------------------------------------------------
diff --git a/doc/README b/doc/README
index dc5c98a..41e3e05 100644
--- a/doc/README
+++ b/doc/README
@@ -1,71 +1,48 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   nspecific language governing permissions and limitations
-   under the License.
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License
+////
 
 Building documentation
-======================
-
-Build the documentation with ``make doc`` or ``make docs``.
+----------------------
 
-If you have an older verbsion of cmake, the documentation may be built when you
-do ``make all``. If so you can disable documentation build with
+Documentation is built when you run `make doc`.
 
-::
-
-    cmake -DBUILD_DOCS=OFF
+(On old versions of cmake it is always built, use `cmake -DBUILD_DOCS=OFF` to
+prevent it being built.)
 
 You need the following tools to build the documentation:
 
-- python-sphinx (1.1.3) for book and man pages (requires python-docutils)
-- doxygen (1.8) for API documentation.
-- graphviz (2.34) for ``dot`` program needed to include diagrams in API documentation.
+* asciidoc (8.6.8) for HTML book and man pages
+* dblatex (0.3.6) for PDF book.
 
 The versions above are known to work, earlier versions may or may not.
 
 Writing documentation
-=====================
-
-Documentation is written in `reStructuedText <http://docutils.sourceforge.net/rst.html>`__
-
-All rst and html format documentation is installed in the share/doc directory.
-Man pages are also installed in the standard share/man locations.
-
-The `dispatch web site <http://qpid.apache.org/components/dispatch-router>`__
-has pre-generated documentation for each release and a random snapshot of the
-trunk.
-
-Documentation sub-directories:
-
--  ``book/``: Book-format documentation.
--  ``man/``: Unix man pages.
--  ``api/``: Generated API documentation.
--  ``notes/``: Developer notes: project information, design notes, or
-   anything else that's primarily of developer interest. These are not
-   installed.
-
-Editing the book.
-=================
+---------------------
 
-Most chapters of the book are restructuredText_ files, you can edit them with
-any text editor. See the `quick reference`_ for a handy guide to syntax.
+Documentation is written in asciidoc markup. Sub-directories:
 
-Some chapters are generated by python scripts rather than being simple
-source files. For example ``schema.md`` is generated by ``schema_md.py``
-from the documentation strings in the management schema
-``qdrouterd.json``.
+* 'book/': Asciidoc source for the user guide.
+* 'man/': Asciidoc source for Unix man pages.
+* 'notes': Developer notes: project information, design notes, or::
+  anything else that's primarily of developer interest. These are not
+  installed.
 
-.. _restructuredText: http://docutils.sourceforge.net/rst.html
-.. _`quick reference`: http://docutils.sourceforge.net/docs/user/rst/quickref.html
+Some book chapters are generated by python scripts rather than being text
+files. For example `schema.txt` is generated by `schema_txt.py` from the
+documentation strings in the management schema `qdrouterd.json`.

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/api/CMakeLists.txt
----------------------------------------------------------------------
diff --git a/doc/api/CMakeLists.txt b/doc/api/CMakeLists.txt
deleted file mode 100644
index 345035c..0000000
--- a/doc/api/CMakeLists.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-##
-## Licensed to the Apache Software Foundation (ASF) under one
-## or more contributor license agreements.  See the NOTICE file
-## distributed with this work for additional information
-## regarding copyright ownership.  The ASF licenses this file
-## to you under the Apache License, Version 2.0 (the
-## "License"); you may not use this file except in compliance
-## with the License.  You may obtain a copy of the License at
-##
-##   http://www.apache.org/licenses/LICENSE-2.0
-##
-## Unless required by applicable law or agreed to in writing,
-## software distributed under the License is distributed on an
-## "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-## KIND, either express or implied.  See the License for the
-## specific language governing permissions and limitations
-## under the License.
-##
-
-set(bin ${CMAKE_CURRENT_BINARY_DIR})
-
-if(USE_DOXYGEN)
-
-  # Create doxygen configuration files.
-  function(configure_doxygen  HTML_OUTPUT INPUT MORE_CONFIG)
-    if(USE_DOT)
-      set(HAVE_DOT yes)
-    else()
-      set(HAVE_DOT no)
-    endif()
-    # Arguments and local variables are used to configure doxygen.in
-    configure_file(
-      ${CMAKE_CURRENT_SOURCE_DIR}/doxygen.in
-      ${CMAKE_CURRENT_BINARY_DIR}/${HTML_OUTPUT}.doxygen)
-  endfunction(configure_doxygen)
-
-  configure_doxygen(api "${CMAKE_SOURCE_DIR}/include" "")
-  configure_doxygen(api_dev "${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/src"
-    "ENABLED_SECTIONS=INTERNAL\nINTERNAL_DOCS=yes\nEXTRACT_ALL=yes")
-
-  # Dependencies: calculated at configuration time so we won't detect
-  # new/removed files till re-configuration. Usually adding/removing sources
-  # will force a re-configuration so by deleting the output to force a re-build
-  # after re-configuration we should catch most cases.
-  file(GLOB_RECURSE API_SOURCES
-    ${CMAKE_SOURCE_DIR}/include/*.h
-    ${CMAKE_SOURCE_DIR}/src/*.h
-    ${CMAKE_SOURCE_DIR}/src/*.c)
-  file(REMOVE_RECURSE ${bin}/api ${bin}/api_dev) # Force rebuild after re-configuration.
-
-  add_custom_command (OUTPUT api api_dev
-    COMMAND ${DOXYGEN_EXECUTABLE} api.doxygen
-    COMMAND ${DOXYGEN_EXECUTABLE} api_dev.doxygen
-    COMMAND ${CMAKE_COMMAND} -E touch api api_dev
-    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/doxygen.in ${API_SOURCES})
-
-  add_custom_target(apidocs DEPENDS api api_dev)
-  add_dependencies(doc apidocs)
-
-  install_doc(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api DESTINATION ${QD_DOC_INSTALL_DIR})
-  install_doc(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/api_dev DESTINATION ${QD_DOC_INSTALL_DIR})
-
-endif(USE_DOXYGEN)

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/api/README
----------------------------------------------------------------------
diff --git a/doc/api/README b/doc/api/README
deleted file mode 100644
index 8bb80fa..0000000
--- a/doc/api/README
+++ /dev/null
@@ -1,33 +0,0 @@
-<!--*-markdown-*-
-
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-nspecific language governing permissions and limitations
-under the License.
-
--->
-
-# API documentation
-
-`api`: User API documentation is generated automatically from [doxygen](http://www.doxygen.org)
-comments in public header files.  You can use the `@internal` tag to mark items
-that should be hidden in the user API docs.
-
-`api_dev` includes everything in `api`, plus anything marked `@internal`, plus
-doc comments from private headers and implementation files in the `src`
-directory. It is a cheap-and-cheerful code-browser for developers.
-
-Please include doc comments for everything in public header files. Use your
-discretion as to when it is useful in private implementation files.

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/api/doxygen.in
----------------------------------------------------------------------
diff --git a/doc/api/doxygen.in b/doc/api/doxygen.in
deleted file mode 100644
index 798973b..0000000
--- a/doc/api/doxygen.in
+++ /dev/null
@@ -1,37 +0,0 @@
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements.  See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership.  The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License.  You may obtain a copy of the License at
-#
-#   http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied.  See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-
-PROJECT_NAME            = "Qpid Dispatch Library (experimental)"
-PROJECT_NUMBER          = ${QPID_DISPATCH_VERSION}
-INPUT                   = ${INPUT}
-HTML_OUTPUT             = ${HTML_OUTPUT}
-
-WARN_IF_UNDOCUMENTED    = NO    # This should be YES, need to fill in missing doc.
-
-STRIP_FROM_PATH         = ${CMAKE_SOURCE_DIR}/include
-DISABLE_INDEX           = yes
-GENERATE_LATEX          = no
-GENERATE_TREEVIEW       = yes
-HAVE_DOT                = ${HAVE_DOT}
-JAVADOC_AUTOBRIEF       = yes
-QUIET                   = yes
-RECURSIVE               = yes
-
-${MORE_CONFIG}
-

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/asciidoc.conf.in
----------------------------------------------------------------------
diff --git a/doc/asciidoc.conf.in b/doc/asciidoc.conf.in
new file mode 100644
index 0000000..9db7110
--- /dev/null
+++ b/doc/asciidoc.conf.in
@@ -0,0 +1,5 @@
+[attributes]
+SYSCONF_INSTALL_DIR=${SYSCONF_INSTALL_DIR}
+CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
+QD_DOC_INSTALL_DIR=${QD_DOC_INSTALL_DIR}
+generated=${CMAKE_CURRENT_BINARY_DIR}

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/addressing.adoc
----------------------------------------------------------------------
diff --git a/doc/book/addressing.adoc b/doc/book/addressing.adoc
new file mode 100644
index 0000000..d138425
--- /dev/null
+++ b/doc/book/addressing.adoc
@@ -0,0 +1,133 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+[[addressing]]
+Addressing
+----------
+
+AMQP addresses are used to control the flow of messages across a network
+of routers. Addresses are used in a number of different places in the
+AMQP 1.0 protocol. They can be used in a specific message in the `to`
+and `reply-to` fields of a message's properties. They are also used
+during the creation of links in the `address` field of a `source` or
+a `target`.
+
+Addresses designate various kinds of entities in a messaging network:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+The syntax of an AMQP address is opaque as far as the router network is
+concerned. A syntactical structure may be used by the administrator that
+creates addresses, but the router treats them as opaque strings. Routers
+consider addresses to be mobile such that any address may be directly
+connected to any router in a network and may move around the topology.
+In cases where messages are broadcast to or balanced across multiple
+consumers, an address may be connected to multiple routers in the
+network.
+
+Addresses have semantics associated with them. When an address is
+created in the network, it is assigned a set of semantics (and access
+rules) during a process called provisioning. The semantics of an address
+control how routers behave when they see the address being used.
+
+Address semantics include the following considerations:
+
+* _Routing pattern_ - direct, multicast, balanced
+* _Undeliverable action_ - drop, hold and retry, redirect
+* _Reliability_ - N destinations, etc.
+
+[[routing-patterns]]
+Routing patterns
+~~~~~~~~~~~~~~~~
+
+Routing patterns constrain the paths that a message can take across a
+network.
+
+[width="100%",cols="18%,82%",options="header",]
+|=======================================================================
+|_Pattern_ |_Description_
+|_Direct_ |Direct routing allows for only one consumer to use an address
+at a time. Messages (or links) follow the lowest cost path across the
+network from the sender to the one receiver.
+
+|_Multicast_ |Multicast routing allows multiple consumers to use the
+same address at the same time. Messages are routed such that each
+consumer receives a copy of the message.
+
+|_Balanced_ |Balanced routing also allows multiple consumers to use the
+same address. In this case, messages are routed to exactly one of the
+consumers, and the network attempts to balance the traffic load across
+the set of consumers using the same address.
+|=======================================================================
+
+[[routing-mechanisms]]
+Routing mechanisms
+~~~~~~~~~~~~~~~~~~
+
+The fact that addresses can be used in different ways suggests that
+message routing can be accomplished in different ways. Before going into
+the specifics of the different routing mechanisms, it would be good to
+first define what is meant by the term __routing__:
+
+_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
+In a network built of multiple routers connected by connections (i.e.,
+nodes and edges in a graph), _routing_ determines which connection to
+use to send a message directly to its destination or one step closer to
+its destination.
+_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________
+
+Each router serves as the terminus of a collection of incoming and
+outgoing links. The links either connect directly to endpoints that
+produce and consume messages, or they connect to other routers in the
+network along previously established connections.
+
+[[message-routing]]
+Message routing
+^^^^^^^^^^^^^^^
+
+Message routing occurs upon delivery of a message and is done based on
+the address in the message's `to` field.
+
+When a delivery arrives on an incoming link, the router extracts the
+address from the delivered message's `to` field and looks the address up
+in its routing table. The lookup results in zero or more outgoing links
+onto which the message shall be resent.
+
+[width="100%",cols="20%,80%",options="header",]
+|=======================================================================
+|_Delivery_ |_Handling_
+|_pre-settled_ |If the arriving delivery is pre-settled (i.e., fire and
+forget), the incoming delivery shall be settled by the router, and the
+outgoing deliveries shall also be pre-settled. In other words, the
+pre-settled nature of the message delivery is propagated across the
+network to the message's destination.
+
+|_unsettled_ |Unsettled delivery is also propagated across the network.
+Because unsettled delivery records cannot be discarded, the router
+tracks the incoming deliveries and keeps the association of the incoming
+deliveries to the resulting outgoing deliveries. This kept association
+allows the router to continue to propagate changes in delivery state
+(settlement and disposition) back and forth along the path which the
+message traveled.
+|=======================================================================

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/addressing.rst
----------------------------------------------------------------------
diff --git a/doc/book/addressing.rst b/doc/book/addressing.rst
deleted file mode 100644
index aa63dbe..0000000
--- a/doc/book/addressing.rst
+++ /dev/null
@@ -1,127 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Addressing
-==========
-
-AMQP addresses are used to control the flow of messages across a network
-of routers. Addresses are used in a number of different places in the
-AMQP 1.0 protocol. They can be used in a specific message in the `to`
-and `reply-to` fields of a message's properties. They are also used
-during the creation of links in the `address` field of a `source` or
-a `target`.
-
-Addresses designate various kinds of entities in a messaging network:
-
--  Endpoint processes that consume data or offer a service
--  Topics that match multiple consumers to multiple producers
--  Entities within a messaging broker:
-   -  Queues
-   -  Durable Topics
-   -  Exchanges
-
-The syntax of an AMQP address is opaque as far as the router network is
-concerned. A syntactical structure may be used by the administrator that
-creates addresses, but the router treats them as opaque strings. Routers
-consider addresses to be mobile such that any address may be directly
-connected to any router in a network and may move around the topology.
-In cases where messages are broadcast to or balanced across multiple
-consumers, an address may be connected to multiple routers in the
-network.
-
-Addresses have semantics associated with them. When an address is
-created in the network, it is assigned a set of semantics (and access
-rules) during a process called provisioning. The semantics of an address
-control how routers behave when they see the address being used.
-
-Address semantics include the following considerations:
-
--  *Routing pattern* - direct, multicast, balanced
--  *Undeliverable action* - drop, hold and retry, redirect
--  *Reliability* - N destinations, etc.
-
-Routing patterns
-----------------
-
-Routing patterns constrain the paths that a message can take across a
-network.
-
-+---------------+-------------------------------------------------------------------------+
-| *Pattern*     | *Description*                                                           |
-+===============+=========================================================================+
-| *Direct*      |Direct routing allows for only one consumer to use an address at a       |
-|               |time. Messages (or links) follow the lowest cost path across the network |
-|               |from the sender to the one receiver.                                     |
-+---------------+-------------------------------------------------------------------------+
-| *Multicast*   |Multicast routing allows multiple consumers to use the same address at   |
-|               |the same time. Messages are routed such that each consumer receives a    |
-|               |copy of the message.                                                     |
-+---------------+-------------------------------------------------------------------------+
-| *Balanced*    |Balanced routing also allows multiple consumers to use the same          |
-|               |address. In this case, messages are routed to exactly one of the         |
-|               |consumers, and the network attempts to balance the traffic load across   |
-|               |the set of consumers using the same address.                             |
-+---------------+-------------------------------------------------------------------------+
-
-Routing mechanisms
-------------------
-
-The fact that addresses can be used in different ways suggests that
-message routing can be accomplished in different ways. Before going into
-the specifics of the different routing mechanisms, it would be good to
-first define what is meant by the term *routing*:
-
-    In a network built of multiple routers connected by connections
-    (i.e., nodes and edges in a graph), *routing* determines which
-    connection to use to send a message directly to its destination or
-    one step closer to its destination.
-
-Each router serves as the terminus of a collection of incoming and
-outgoing links. The links either connect directly to endpoints that
-produce and consume messages, or they connect to other routers in the
-network along previously established connections.
-
-Message routing
-~~~~~~~~~~~~~~~
-
-Message routing occurs upon delivery of a message and is done based on
-the address in the message's `to` field.
-
-When a delivery arrives on an incoming link, the router extracts the
-address from the delivered message's `to` field and looks the address
-up in its routing table. The lookup results in zero or more outgoing
-links onto which the message shall be resent.
-
-+-----------------+-----------------------------------------------------------------------+
-| *Delivery*      | *Handling*                                                            |
-+=================+=======================================================================+
-| *pre-settled*   |If the arriving delivery is pre-settled (i.e., fire and forget), the   |
-|                 |incoming delivery shall be settled by the router, and the outgoing     |
-|                 |deliveries shall also be pre-settled. In other words, the pre-settled  |
-|                 |nature of the message delivery is propagated across the network to the |
-|                 |message's destination.                                                 |
-|                 |                                                                       |
-+-----------------+-----------------------------------------------------------------------+
-| *unsettled*     |Unsettled delivery is also propagated across the network. Because      |
-|                 |unsettled delivery records cannot be discarded, the router tracks the  |
-|                 |incoming deliveries and keeps the association of the incoming          |
-|                 |deliveries to the resulting outgoing deliveries. This kept association |
-|                 |allows the router to continue to propagate changes in delivery state   |
-|                 |(settlement and disposition) back and forth along the path which the   |
-|                 |message traveled.                                                      |
-|                 |                                                                       |
-+-----------------+-----------------------------------------------------------------------+

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/amqp-mapping.adoc
----------------------------------------------------------------------
diff --git a/doc/book/amqp-mapping.adoc b/doc/book/amqp-mapping.adoc
new file mode 100644
index 0000000..4f540c5
--- /dev/null
+++ b/doc/book/amqp-mapping.adoc
@@ -0,0 +1,175 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+[[amqp-mapping]]
+AMQP Mapping
+------------
+
+Dispatch Router is an AMQP router and as such, it provides extensions,
+code-points, and semantics for routing over AMQP. This page documents the
+details of Dispatch Router's use of AMQP.
+
+[[message-annotations]]
+Message Annotations
+~~~~~~~~~~~~~~~~~~~
+
+The following Message Annotation fields are defined by Dispatch Router:
+
+[width="100%",cols="23%,19%,58%",options="header",]
+|=======================================================================
+|_Field_ |_Type_ |_Description_
+|x-opt-qd.ingress |string |The identity of the ingress router for a
+message-routed message. The ingress router is the first router
+encountered by a transiting message. The router will, if this field is
+present, leave it unaltered. If the field is not present, the router
+shall insert the field with its own identity.
+
+|x-opt-qd.trace |list of string |The list of routers through which this
+message-routed message has transited. If this field is not present, the
+router shall do nothing. If the field is present, the router shall
+append its own identity to the end of the list.
+
+|x-opt-qd.to |string |To-Override for message-routed messages. If this
+field is present, the address in this field shall be used for routing in
+lieu of the _to_ field in the message properties. A router may append,
+remove, or modify this annotation field depending on the policy in place
+for routing the message.
+
+|x-opt-qd.phase |integer |The address-phase, if not zero, for messages
+flowing between routers.
+|=======================================================================
+
+[[sourcetarget-capabilities]]
+Source/Target Capabilities
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following Capability values are used in Sources and Targets.
+
+[width="100%",cols="19%,81%",options="header",]
+|=======================================================================
+|_Capability_ |_Description_
+|qd.router |This capability is added to sources and targets that are
+used for inter-router message exchange. This capability denotes a link
+used for router-control messages flowing between routers.
+
+|qd.router-data |This capability is added to sources and targets that
+are used for inter-router message exchange. This capability denotes a
+link used for user messages being message-routed across an inter-router
+connection.
+|=======================================================================
+
+[[dynamic-node-properties]]
+Dynamic-Node-Properties
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The following dynamic-node-properties are used by Dispatch in Sources.
+
+[width="100%",cols="23%,77%",options="header",]
+|=======================================================================
+|_Property_ |_Description_
+|x-opt-qd.address |The node address describing the destination desired
+for a dynamic source. If this is absent, the router will terminate any
+dynamic receivers. If this address is present, the router will use the
+address to route the dynamic link attach to the proper destination
+container.
+|=======================================================================
+
+[[addresses-and-address-formats]]
+Addresses and Address Formats
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following AMQP addresses and address patterns are used within
+Dispatch Router.
+
+[[address-patterns]]
+Address Patterns
+^^^^^^^^^^^^^^^^
+
+[width="100%",cols="38%,62%",options="header",]
+|=======================================================================
+|_Pattern_ |_Description_
+|`_local/<addr>` |An address that references a locally attached endpoint.
+Messages using this address pattern shall not be routed over more than
+one link.
+
+|`_topo/0/<router>/<addr>` |
+An address that references an endpoint attached to a specific router
+node in the network topology. Messages with addresses that follow this
+pattern shall be routed along the shortest path to the specified router.
+Note that addresses of this form are a-priori routable in that the
+address itself contains enough information to route the message to its
+destination.
+
+The '0' component immediately preceding the router-id is a placeholder
+for an _area_ which may be used in the future if area routing is
+implemented.
+
+|`<addr>` |A mobile address. An address of this format represents an
+endpoint or a set of distinct endpoints that are attached to the network
+in arbitrary locations. It is the responsibility of the router network
+to determine which router nodes are valid destinations for mobile
+addresses.
+|=======================================================================
+
+[[supported-addresses]]
+Supported Addresses
+^^^^^^^^^^^^^^^^^^^
+
+[width="100%",cols="36%,64%",options="header",]
+|=======================================================================
+|_Address_ |_Description_
+|`$management` |The management agent on the attached router/container.
+This address would be used by an endpoint that is a management
+client/console/tool wishing to access management data from the attached
+container.
+
+|`_topo/0/Router.E/$management` |The management agent at Router.E in area
+0. This address would be used by a management client wishing to access
+management data from a specific container that is reachable within the
+network.
+
+|`_local/qdhello` |The router entity in each of the connected routers.
+This address is used to communicate with neighbor routers and is
+exclusively for the HELLO discovery protocol.
+
+|`_local/qdrouter` |The router entity in each of the connected routers.
+This address is used by a router to communicate with other routers in
+the network.
+
+|`_topo/0/Router.E/qdrouter` |The router entity at the specifically
+indicated router. This address form is used by a router to communicate
+with a specific router that may or may not be a neighbor.
+|=======================================================================
+
+[[implementation-of-the-amqp-management-specification]]
+Implementation of the AMQP Management Specification
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
+emerging AMQP Management specification (draft 9).
+
+Differences from the specification:
+
+-  The `name` attribute is not required when an entity is created. If
+   not supplied it will be set to the same value as the system-generated
+   "identity" attribute. Otherwise it is treated as per the standard.
+-  The `REGISTER` and `DEREGISTER` operations are not implemented. The router
+   automatically discovers peer routers via the router network and makes
+   their management addresses available via the standard `GET-MGMT-NODES`
+   operation.

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/amqp-mapping.rst
----------------------------------------------------------------------
diff --git a/doc/book/amqp-mapping.rst b/doc/book/amqp-mapping.rst
deleted file mode 100644
index 465acd9..0000000
--- a/doc/book/amqp-mapping.rst
+++ /dev/null
@@ -1,208 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-AMQP Mapping
-============
-
-Dispatch Router is an AMQP router and as such, it provides extensions,
-code-points, and semantics for routing over AMQP. This page documents the
-details of Dispatch Router's use of AMQP.
-
-Message Annotations
--------------------
-
-The following Message Annotation fields are defined by Dispatch Router:
-
-+--------------------+------------------+-------------------------------------------------------+
-| *Field*            | *Type*           | *Description*                                         |
-+====================+==================+=======================================================+
-| x-opt-qd.ingress   | string           |The identity of the ingress router for a message-routed|
-|                    |                  |message. The ingress router is the first router        |
-|                    |                  |encountered by a transiting message. The router will,  |
-|                    |                  |if this field is present, leave it unaltered. If the   |
-|                    |                  |field is not present, the router shall insert the field|
-|                    |                  |with its own identity.                                 |
-|                    |                  |                                                       |
-|                    |                  |                                                       |
-|                    |                  |                                                       |
-+--------------------+------------------+-------------------------------------------------------+
-| x-opt-qd.trace     | list of string   |The list of routers through which this message-routed  |
-|                    |                  |message has transited. If this field is not present,   |
-|                    |                  |the router shall do nothing. If the field is present,  |
-|                    |                  |the router shall append its own identity to the end of |
-|                    |                  |the list.                                              |
-|                    |                  |                                                       |
-|                    |                  |                                                       |
-+--------------------+------------------+-------------------------------------------------------+
-| x-opt-qd.to        | string           |To-Override for message-routed messages. If this field |
-|                    |                  |is present, the address in this field shall be used for|
-|                    |                  |routing in lieu of the *to* field in the message       |
-|                    |                  |properties. A router may append, remove, or modify this|
-|                    |                  |annotation field depending on the policy in place for  |
-|                    |                  |routing the message.                                   |
-|                    |                  |                                                       |
-|                    |                  |                                                       |
-|                    |                  |                                                       |
-+--------------------+------------------+-------------------------------------------------------+
-| x-opt-qd.phase     | integer          |The address-phase, if not zero, for messages flowing   |
-|                    |                  |between routers.                                       |
-|                    |                  |                                                       |
-+--------------------+------------------+-------------------------------------------------------+
-
-Source/Target Capabilities
---------------------------
-
-The following Capability values are used in Sources and Targets.
-
-+----------------+----------------------------------------------------------------------------+
-| *Capability*   | *Description*                                                              |
-+================+============================================================================+
-| qd.router      |This capability is added to sources and targets that are used for           |
-|                |inter-router message exchange.  This capability denotes a link used for     |
-|                |router-control messages flowing between routers.                            |
-+----------------+----------------------------------------------------------------------------+
-| qd.router-data |This capability is added to sources and targets that are used for           |
-|                |inter-router message exchange.  This capability denotes a link used for     |
-|                |user messages being message-routed across an inter-router connection.       |
-+----------------+----------------------------------------------------------------------------+
-
-Dynamic-Node-Properties
------------------------
-
-The following dynamic-node-properties are used by Dispatch in Sources.
-
-+--------------------+-----------------------------------------------------------------------+
-| *Property*         | *Description*                                                         |
-+====================+=======================================================================+
-| x-opt-qd.address   |The node address describing the destination desired for a dynamic      |
-|                    |source. If this is absent, the router will terminate any dynamic       |
-|                    |receivers. If this address is present, the router will use the address |
-|                    |to route the dynamic link attach to the proper destination container.  |
-|                    |                                                                       |
-+--------------------+-----------------------------------------------------------------------+
-
-Addresses and Address Formats
------------------------------
-
-The following AMQP addresses and address patterns are used within
-Dispatch Router.
-
-Address Patterns
-~~~~~~~~~~~~~~~~
-
-+--------------------------------+-------------------------------------------------------+
-| *Pattern*                      | *Description*                                         |
-+================================+=======================================================+
-| `_local/<addr>`                |An address that references a locally attached          |
-|                                |endpoint. Messages using this address pattern shall not|
-|                                |be routed over more than one link.                     |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-+--------------------------------+-------------------------------------------------------+
-| `_topo/0/<router>/<addr>`      |An address that references an endpoint attached to a   |
-|                                |specific router node in the network topology. Messages |
-|                                |with addresses that follow this pattern shall be routed|
-|                                |along the shortest path to the specified router. Note  |
-|                                |that addresses of this form are a-priori routable in   |
-|                                |that the address itself contains enough information to |
-|                                |route the message to its destination.                  |
-|                                |                                                       |
-|                                |The '0' component immediately preceding the router-id  |
-|                                |is a placeholder for an _area_ which may be used in    |
-|                                |the future if area routing is implemented.             |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-+--------------------------------+-------------------------------------------------------+
-| `<addr>`                       |A mobile address. An address of this format represents |
-|                                |an endpoint or a set of distinct endpoints that are    |
-|                                |attached to the network in arbitrary locations. It is  |
-|                                |the responsibility of the router network to determine  |
-|                                |which router nodes are valid destinations for mobile   |
-|                                |addresses.                                             |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-|                                |                                                       |
-+--------------------------------+-------------------------------------------------------+
-
-Supported Addresses
-~~~~~~~~~~~~~~~~~~~
-
-+---------------------------------+------------------------------------------------------------+
-| *Address*                       | *Description*                                              |
-+=================================+============================================================+
-| `$management`                   |The management agent on the attached router/container. This |
-|                                 |address would be used by an endpoint that is a management   |
-|                                 |client/console/tool wishing to access management data from  |
-|                                 |the attached container.                                     |
-+---------------------------------+------------------------------------------------------------+
-| `_topo/0/Router.E/$management`  |The management agent at Router.E in area 0. This address    |
-|                                 |would be used by a management client wishing to access      |
-|                                 |management data from a specific container that is reachable |
-|                                 |within the network.                                         |
-+---------------------------------+------------------------------------------------------------+
-| `_local/qdhello`                |The router entity in each of the connected routers. This    |
-|                                 |address is used to communicate with neighbor routers and is |
-|                                 |exclusively for the HELLO discovery protocol.               |
-+---------------------------------+------------------------------------------------------------+
-| `_local/qdrouter`               |The router entity in each of the connected routers. This    |
-|                                 |address is used by a router to communicate with other       |
-|                                 |routers in the network.                                     |
-+---------------------------------+------------------------------------------------------------+
-| `_topo/0/Router.E/qdrouter`     |The router entity at the specifically indicated router. This|
-|                                 |address form is used by a router to communicate with a      |
-|                                 |specific router that may or may not be a neighbor.          |
-+---------------------------------+------------------------------------------------------------+
-
-Implementation of the AMQP Management Specification
----------------------------------------------------
-
-Qpid Dispatch is manageable remotely via AMQP. It is compliant with the
-emerging AMQP Management specification (draft 9).
-
-Differences from the specification:
-
--  The `name` attribute is not required when an entity is created. If
-   not supplied it will be set to the same value as the system-generated
-   "identity" attribute. Otherwise it is treated as per the standard.
--  The `REGISTER` and `DEREGISTER` operations are not implemented. The router
-   automatically discovers peer routers via the router network and makes
-   their management addresses available via the standard GET-MGMT-NODES
-   operation.

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/auto_links.adoc
----------------------------------------------------------------------
diff --git a/doc/book/auto_links.adoc b/doc/book/auto_links.adoc
new file mode 100644
index 0000000..7703601
--- /dev/null
+++ b/doc/book/auto_links.adoc
@@ -0,0 +1,257 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+[[indirect-waypoints-and-auto-links]]
+Indirect Waypoints and Auto-Links
+---------------------------------
+
+This feature was introduced in Qpid Dispatch 0.6. It is a significant
+improvement on an earlier somewhat experimental feature called
+Waypoints.
+
+Auto-link is a feature of Qpid Dispatch Router that enables a router to
+actively attach a link to a node on an external AMQP container. The
+obvious application for this feature is to route messages through a
+queue on a broker, but other applications are possible as well.
+
+An auto-link manages the lifecycle of one AMQP link. If messages are to
+be routed to and from a queue on a broker, then two auto-links are
+needed: one for sending messages to the queue and another for receiving
+messages from the queue. The container to which an auto-link attempts to
+attach may be identified in one of two ways:
+
+_________________________________________________________________________________________
+* The name of the connector/listener that resulted in the connection of
+the container, or
+* The AMQP container-id of the remote container.
+_________________________________________________________________________________________
+
+[[queue-waypoint-example]]
+Queue Waypoint Example
+~~~~~~~~~~~~~~~~~~~~~~
+
+Here is an example configuration for routing messages deliveries through
+a pair of queues on a broker:
+
+----
+connector {
+    name: broker
+    role: route-container
+    host: <hostname>
+    port: <port>
+    saslMechanisms: ANONYMOUS
+}
+
+address {
+    prefix: queue
+    waypoint: yes
+}
+
+autoLink {
+    addr: queue.first
+    dir: in
+    connection: broker
+}
+
+autoLink {
+    addr: queue.first
+    dir: out
+    connection: broker
+}
+
+autoLink {
+    addr: queue.second
+    dir: in
+    connection: broker
+}
+
+autoLink {
+    addr: queue.second
+    dir: out
+    connection: broker
+}
+----
+
+The +address+ entity identifies a namespace 'queue.' that will be used
+for routing messages through queues via autolinks. The four +autoLink+ entities
+identify the head and tail of two queues on the broker that will be connected
+via auto-links.
+
+If there is no broker connected, the auto-links shall remain
+_inactive_. This can be observed by using the `qdstat` tool:
+
+---------------------------
+$ qdstat --autolinks
+AutoLinks
+  addr          dir  phase  link  status    lastErr
+  ===================================================
+  queue.first   in   1            inactive
+  queue.first   out  0            inactive
+  queue.second  in   1            inactive
+  queue.second  out  0            inactive
+---------------------------
+
+If a broker comes online with a queue called 'queue.first', the
+auto-links will attempt to activate:
+
+--------------------
+$ qdstat --autolinks
+AutoLinks
+  addr          dir  phase  link  status  lastErr
+  ======================================================================
+  queue.first   in   1      6     active
+  queue.first   out  0      7     active
+  queue.second  in   1            failed  Node not found: queue.second
+  queue.second  out  0            failed  Node not found: queue.second
+--------------------
+
+Note that two of the auto-links are in _failed_ state because the queue
+does not exist on the broker.
+
+If we now use the Qpid Proton example application `simple_send.py` to send
+three messages to 'queue.first' via the router:
+
+--------------------------
+$ python simple_send.py -a 127.0.0.1/queue.first -m3
+all messages confirmed
+--------------------------
+
+and then look at the address statistics on the router:
+
+----------------------------
+$ qdstat -a
+Router Addresses
+  class   addr           phs  distrib   in-proc  local  remote  cntnr  in  out  thru  to-proc  from-proc
+  ========================================================================================================
+  mobile  queue.first    1    balanced  0        0      0       0      0   0    0     0        0
+  mobile  queue.first    0    balanced  0        1      0       0      3   3    0     0        0
+----------------------------
+
+we see that 'queue.first' appears twice in the list of addresses. The
++phs+, or phase column shows that there are two phases for the
+address. Phase '0' is for routing message deliveries from producers to
+the tail of the queue (the +out+ auto-link associated with the queue).
+Phase 1 is for routing deliveries from the head of the queue to
+subscribed consumers.
+
+Note that three deliveries have been counted in the "in" and "out"
+columns for phase '0'. The "in" column represents the three messages
+that arrived from `simple_send.py` and the +out+ column represents the three
+deliveries to the queue on the broker.
+
+If we now use `simple_recv.py` to receive three messages from this address:
+
+--------------
+$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
+{u'sequence': int32(1)}
+{u'sequence': int32(2)}
+{u'sequence': int32(3)}
+--------------
+
+We receive the three queued messages. Looking at the addresses again, we
+see that phase 1 was used to deliver those messages from the queue to
+the consumer.
+
+----------------------------
+$ qdstat -a
+Router Addresses
+  class   addr           phs  distrib   in-proc  local  remote  cntnr  in  out  thru  to-proc  from-proc
+  ========================================================================================================
+  mobile  queue.first    1    balanced  0        0      0       0      3   3    0     0        0
+  mobile  queue.first    0    balanced  0        1      0       0      3   3    0     0        0
+----------------------------
+
+Note that even in a multi-router network, and with multiple producers
+and consumers for 'queue.first', all deliveries will be routed through
+the queue on the connected broker.
+
+[[sharded-queue-example]]
+Sharded Queue Example
+~~~~~~~~~~~~~~~~~~~~~
+
+Here is an extension of the above example to illustrate how Qpid
+Dispatch Router can be used to create a distributed queue in which
+multiple brokers share the message-queueing load.
+
+----
+connector {
+    name: broker1
+    role: route-container
+    host: <hostname>
+    port: <port>
+    saslMechanisms: ANONYMOUS
+}
+
+connector {
+    name: broker2
+    role: route-container
+    host: <hostname>
+    port: <port>
+    saslMechanisms: ANONYMOUS
+}
+
+address {
+    prefix: queue
+    waypoint: yes
+}
+
+autoLink {
+    addr: queue.first
+    dir: in
+    connection: broker1
+}
+
+autoLink {
+    addr: queue.first
+    dir: out
+    connection: broker1
+}
+
+autoLink {
+    addr: queue.first
+    dir: in
+    connection: broker2
+}
+
+autoLink {
+    addr: queue.first
+    dir: out
+    connection: broker2
+}
+----
+
+In the above configuration, there are two instances of _queue.first_ on
+brokers 1 and 2. Message traffic from producers to address _queue.first_
+shall be balanced between the two instance and messages from the queues
+shall be balanced across the collection of subscribers to the same
+address.
+
+[[dynamically-adding-shards]]
+Dynamically Adding Shards
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Since configurable entities in the router can also be accessed via the
+management protocol, we can remotely add a shard to the above example
+using `qdmanage`:
+
+----
+qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
+qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
+qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3
+----

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/4ba68bb8/doc/book/auto_links.rst
----------------------------------------------------------------------
diff --git a/doc/book/auto_links.rst b/doc/book/auto_links.rst
deleted file mode 100644
index 5cbb416..0000000
--- a/doc/book/auto_links.rst
+++ /dev/null
@@ -1,251 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-     http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Indirect Waypoints and Auto-Links
-=================================
-
-This feature was introduced in Qpid Dispatch 0.6.  It is a significant
-improvement on an earlier somewhat experimental feature called
-Waypoints.
-
-Auto-link is a feature of Qpid Dispatch Router that enables a router
-to actively attach a link to a node on an external AMQP container.
-The obvious application for this feature is to route messages through
-a queue on a broker, but other applications are possible as well.
-
-An auto-link manages the lifecycle of one AMQP link.  If messages are
-to be routed to and from a queue on a broker, then two auto-links are
-needed: one for sending messages to the queue and another for
-receiving messages from the queue.  The container to which an
-auto-link attempts to attach may be identified in one of two ways:
-
- - The name of the connector/listener that resulted in the connection
-   of the container, or
- - The AMQP container-id of the remote container.
-
-Queue Waypoint Example
-----------------------
-
-Here is an example configuration for routing messages deliveries
-through a pair of queues on a broker:
-
-::
-
-    connector {
-        name: broker
-        role: route-container
-        host: <hostname>
-        port: <port>
-        saslMechanisms: ANONYMOUS
-    }
-
-    address {
-        prefix: queue
-        waypoint: yes
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: in
-        connection: broker
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: out
-        connection: broker
-    }
-
-    autoLink {
-        addr: queue.second
-        dir: in
-        connection: broker
-    }
-
-    autoLink {
-        addr: queue.second
-        dir: out
-        connection: broker
-    }
-
-The *address* entity identifies a namespace (queue.*) that will be
-used for routing messages through queues via autolinks.  The four
-*autoLink* entities identify the head and tail of two queues on the
-broker that will be connected via auto-links.
-
-If there is no broker connected, the auto-links shall remain
-*inactive*.  This can be observed by using the *qdstat* tool:
-
-::
-
-    $ qdstat --autolinks
-    AutoLinks
-      addr          dir  phase  link  status    lastErr
-      ===================================================
-      queue.first   in   1            inactive  
-      queue.first   out  0            inactive  
-      queue.second  in   1            inactive  
-      queue.second  out  0            inactive  
-
-If a broker comes online with a queue called *queue.first*, the
-auto-links will attempt to activate:
-
-::
-
-    $ qdstat --autolinks
-    AutoLinks
-      addr          dir  phase  link  status  lastErr
-      ======================================================================
-      queue.first   in   1      6     active  
-      queue.first   out  0      7     active  
-      queue.second  in   1            failed  Node not found: queue.second
-      queue.second  out  0            failed  Node not found: queue.second
-
-Note that two of the auto-links are in *failed* state because the
-queue does not exist on the broker.
-
-If we now use the Qpid Proton example application *simple_send* to
-send three messages to queue.first via the router:
-
-::
-
-    $ python simple_send.py -a 127.0.0.1/queue.first -m3
-    all messages confirmed
-
-and then look at the address statistics on the router:
-
-::
-
-    $ qdstat -a
-    Router Addresses
-      class   addr           phs  distrib   in-proc  local  remote  cntnr  in  out  thru  to-proc  from-proc
-      ========================================================================================================
-      mobile  queue.first    1    balanced  0        0      0       0      0   0    0     0        0
-      mobile  queue.first    0    balanced  0        1      0       0      3   3    0     0        0
-
-we see that *queue.first* appears twice in the list of addresses.  The
-*phs*, or phase column shows that there are two phases for the
-address.  Phase '0' is for routing message deliveries from producers
-to the tail of the queue (the *out* auto-link associated with the
-queue).  Phase '1' is for routing deliveries from the head of the
-queue to subscribed consumers.
-
-Note that three deliveries have been counted in the "in" and "out"
-columns for phase '0'.  The "in" column represents the three messages
-that arrived from simple_send and the "out" column represents the
-three deliveries to the queue on the broker.
-
-If we now use *simple_recv* to receive three messages from this
-address:
-
-::
-
-    $ python simple_recv_noignore.py -a 127.0.0.1:5672/queue.first -m3
-    {u'sequence': int32(1)}
-    {u'sequence': int32(2)}
-    {u'sequence': int32(3)}
-
-We receive the three queued messages.  Looking at the addresses again,
-we see that phase '1' was used to deliver those messages from the
-queue to the consumer.
-
-::
-
-    $ qdstat -a
-    Router Addresses
-      class   addr           phs  distrib   in-proc  local  remote  cntnr  in  out  thru  to-proc  from-proc
-      ========================================================================================================
-      mobile  queue.first    1    balanced  0        0      0       0      3   3    0     0        0
-      mobile  queue.first    0    balanced  0        1      0       0      3   3    0     0        0
-
-Note that even in a multi-router network, and with multiple producers
-and consumers for *queue.first*, all deliveries will be routed through
-the queue on the connected broker.
-
-Sharded Queue Example
----------------------
-
-Here is an extension of the above example to illustrate how Qpid
-Dispatch Router can be used to create a distributed queue in which
-multiple brokers share the message-queueing load.
-
-::
-
-    connector {
-        name: broker1
-        role: route-container
-        host: <hostname>
-        port: <port>
-        saslMechanisms: ANONYMOUS
-    }
-
-    connector {
-        name: broker2
-        role: route-container
-        host: <hostname>
-        port: <port>
-        saslMechanisms: ANONYMOUS
-    }
-
-    address {
-        prefix: queue
-        waypoint: yes
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: in
-        connection: broker1
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: out
-        connection: broker1
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: in
-        connection: broker2
-    }
-
-    autoLink {
-        addr: queue.first
-        dir: out
-        connection: broker2
-    }
-
-In the above configuration, there are two instances of *queue.first*
-on brokers 1 and 2.  Message traffic from producers to address
-*queue.first* shall be balanced between the two instance and messages
-from the queues shall be balanced across the collection of subscribers
-to the same address.
-
-Dynamically Adding Shards
--------------------------
-
-Since configurable entities in the router can also be accessed via the
-management protocol, we can remotely add a shard to the above example
-using *qdmanage*:
-
-::
-
-    qdmanage create --type org.apache.qpid.dispatch.connector host=<host> port=<port> name=broker3
-    qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=in connection=broker3
-    qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink addr=queue.first dir=out connection=broker3
-


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org


Mime
View raw message