couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nsla...@apache.org
Subject [12/19] git commit: moving things around and preparing base automake setup
Date Sat, 29 Sep 2012 16:11:18 GMT
moving things around and preparing base automake setup


Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/0357f044
Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/0357f044
Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/0357f044

Branch: refs/heads/docs
Commit: 0357f04435f18dd2da362d823dd903a1b1baeffc
Parents: 20cc4af
Author: Noah Slater <nslater@apache.org>
Authored: Sat Sep 29 16:54:38 2012 +0100
Committer: Noah Slater <nslater@apache.org>
Committed: Sat Sep 29 16:54:38 2012 +0100

----------------------------------------------------------------------
 configure.ac                         |    1 +
 share/Makefile.am                    |    2 +
 share/docs/Makefile.am               |   53 +
 share/docs/demo.mk                   |    2 +-
 share/docs/rst/TODO.txt              |   11 -
 share/docs/rst/api-basics.rst        |  447 ---------
 share/docs/rst/api/authn.rst         |   29 -
 share/docs/rst/api/configuration.rst |  285 ------
 share/docs/rst/api/database.rst      | 1451 ----------------------------
 share/docs/rst/api/dbmaint.rst       |    3 -
 share/docs/rst/api/design.rst        | 1252 ------------------------
 share/docs/rst/api/documents.rst     |  919 ------------------
 share/docs/rst/api/local.rst         |  157 ---
 share/docs/rst/api/misc.rst          |  793 ----------------
 share/docs/rst/api/reference.rst     |   16 -
 share/docs/rst/changes.rst           |   31 -
 share/docs/rst/commonjs.rst          |   44 -
 share/docs/rst/conf.py               |  247 -----
 share/docs/rst/config_reference.rst  |  276 ------
 share/docs/rst/configuring.rst       |   83 --
 share/docs/rst/ddocs.rst             |    7 -
 share/docs/rst/errors.rst            |   25 -
 share/docs/rst/http-proxying.rst     |   82 --
 share/docs/rst/index.rst             |   36 -
 share/docs/rst/intro.rst             |  297 ------
 share/docs/rst/json-structure.rst    |  401 --------
 share/docs/rst/os-daemons.rst        |   38 -
 share/docs/rst/range.rst             |   60 --
 share/docs/rst/release.rst           |   35 -
 share/docs/rst/replication.rst       |  371 --------
 share/docs/rst/ssl.rst               |   97 --
 share/docs/src/api-basics.rst        |  459 +++++++++
 share/docs/src/api/authn.rst         |   41 +
 share/docs/src/api/configuration.rst |  297 ++++++
 share/docs/src/api/database.rst      | 1463 +++++++++++++++++++++++++++++
 share/docs/src/api/dbmaint.rst       |   15 +
 share/docs/src/api/design.rst        | 1264 +++++++++++++++++++++++++
 share/docs/src/api/documents.rst     |  931 ++++++++++++++++++
 share/docs/src/api/local.rst         |  169 ++++
 share/docs/src/api/misc.rst          |  805 ++++++++++++++++
 share/docs/src/api/reference.rst     |   28 +
 share/docs/src/changes.rst           |   43 +
 share/docs/src/commonjs.rst          |   56 ++
 share/docs/src/conf.py               |  247 +++++
 share/docs/src/config_reference.rst  |  288 ++++++
 share/docs/src/configuring.rst       |   95 ++
 share/docs/src/ddocs.rst             |   19 +
 share/docs/src/errors.rst            |   37 +
 share/docs/src/http-proxying.rst     |   94 ++
 share/docs/src/index.rst             |   48 +
 share/docs/src/intro.rst             |  309 ++++++
 share/docs/src/json-structure.rst    |  413 ++++++++
 share/docs/src/os-daemons.rst        |   50 +
 share/docs/src/range.rst             |   72 ++
 share/docs/src/release.rst           |   47 +
 share/docs/src/replication.rst       |  383 ++++++++
 share/docs/src/ssl.rst               |  109 +++
 57 files changed, 7839 insertions(+), 7494 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/configure.ac
----------------------------------------------------------------------
diff --git a/configure.ac b/configure.ac
index 7ce4842..1431e50 100644
--- a/configure.ac
+++ b/configure.ac
@@ -549,6 +549,7 @@ AC_CONFIG_FILES([etc/logrotate.d/Makefile])
 AC_CONFIG_FILES([etc/windows/Makefile])
 AC_CONFIG_FILES([etc/Makefile])
 AC_CONFIG_FILES([share/Makefile])
+AC_CONFIG_FILES([share/docs/Makefile])
 AC_CONFIG_FILES([src/Makefile])
 AC_CONFIG_FILES([src/couch_index/Makefile])
 AC_CONFIG_FILES([src/couch_mrview/Makefile])

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/Makefile.am
----------------------------------------------------------------------
diff --git a/share/Makefile.am b/share/Makefile.am
index aa73b6b..b71fb73 100644
--- a/share/Makefile.am
+++ b/share/Makefile.am
@@ -10,6 +10,8 @@
 ## License for the specific language governing permissions and limitations under
 ## the License.
 
+SUBDIRS = docs
+
 JS_FILE = server/main.js
 
 JS_FILE_COMPONENTS = \

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/Makefile.am
----------------------------------------------------------------------
diff --git a/share/docs/Makefile.am b/share/docs/Makefile.am
new file mode 100644
index 0000000..0a039f5
--- /dev/null
+++ b/share/docs/Makefile.am
@@ -0,0 +1,53 @@
+## Licensed 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.
+
+# @@ can we remove _static?
+
+# @@ what is the license for conf.py?
+
+EXTRA_DIST = \
+	demo.mk \
+	images/epub-icon.png \
+	images/futon-createdb.png \
+	images/futon-editdoc.png \
+	images/futon-editeddoc.png \
+	images/futon-overview.png \
+	images/futon-replform.png \
+	make.bat \
+	Makefile.am \
+	src/_static \ 
+	src/api/authn.rst \
+	src/api/configuration.rst \
+	src/api/database.rst \
+	src/api/dbmaint.rst \
+	src/api/design.rst \
+	src/api/documents.rst \
+	src/api/local.rst \
+	src/api/misc.rst \
+	src/api/reference.rst \
+	src/api-basics.rst \
+	src/changes.rst \
+	src/commonjs.rst \
+	src/conf.py \
+	src/config_reference.rst \
+	src/configuring.rst \
+	src/ddocs.rst \
+	src/errors.rst \
+	src/http-proxying.rst \
+	src/index.rst \
+	src/intro.rst \
+	src/json-structure.rst \
+	src/os-daemons.rst \
+	src/range.rst \
+	src/release.rst \
+	src/replication.rst \
+	src/ssl.rst
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/demo.mk
----------------------------------------------------------------------
diff --git a/share/docs/demo.mk b/share/docs/demo.mk
index 61d08ac..28a1541 100644
--- a/share/docs/demo.mk
+++ b/share/docs/demo.mk
@@ -10,7 +10,7 @@ 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) rst
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) src
 # the i18n builder cannot share the environment and doctrees with the others
 I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
 

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/manual/.gitignore
----------------------------------------------------------------------
diff --git a/share/docs/manual/.gitignore b/share/docs/manual/.gitignore
deleted file mode 100644
index e69de29..0000000

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/TODO.txt
----------------------------------------------------------------------
diff --git a/share/docs/rst/TODO.txt b/share/docs/rst/TODO.txt
deleted file mode 100644
index 00fd3ba..0000000
--- a/share/docs/rst/TODO.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-- Actually explain configuration options in configuring [reference]
-- Write some documentation on (writing) views [views]
-- Expand view documentation in reference (skipping and grouping) [api/design]
-- Write documentation on the changes feed [changes]
-- Share content from 1.1 in main docs somehow (ssl, proxying)
-- Fill out db maintenance reference (?) [api/dbmaint]
-- Fill out authentication reference [api/authn]
-- Document missing APIs [api/database]
-- Add table with list of APIs [api/design]
-- Update documentation for 1.2
-- Update documentation for master

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/_static/.gitignore
----------------------------------------------------------------------
diff --git a/share/docs/rst/_static/.gitignore b/share/docs/rst/_static/.gitignore
deleted file mode 100644
index e69de29..0000000

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/api-basics.rst
----------------------------------------------------------------------
diff --git a/share/docs/rst/api-basics.rst b/share/docs/rst/api-basics.rst
deleted file mode 100644
index 383f1f9..0000000
--- a/share/docs/rst/api-basics.rst
+++ /dev/null
@@ -1,447 +0,0 @@
-.. _api-basics:
-
-===========
-CouchDB API
-===========
-
-The CouchDB API is the primary method of interfacing to a CouchDB
-instance. Requests are made using HTTP and requests are used to request
-information from the database, store new data, and perform views and
-formatting of the information stored within the documents.
-
-Requests to the API can be categorised by the different areas of the
-CouchDB system that you are accessing, and the HTTP method used to send
-the request. Different methods imply different operations, for example
-retrieval of information from the database is typically handled by the
-``GET`` operation, while updates are handled by either a ``POST`` or
-``PUT`` request. There are some differences between the information that
-must be supplied for the different methods. For a guide to the basic
-HTTP methods and request structure, see :ref:`api-format`.
-
-For nearly all operations, the submitted data, and the returned data
-structure, is defined within a JavaScript Object Notation (JSON) object.
-Basic information on the content and data types for JSON are provided in
-:ref:`json`.
-
-Errors when accessing the CouchDB API are reported using standard HTTP
-Status Codes. A guide to the generic codes returned by CouchDB are
-provided in :ref:`errors`.
-
-When accessing specific areas of the CouchDB API, specific information
-and examples on the HTTP methods and request, JSON structures, and error
-codes are provided. For a guide to the different areas of the API, see
-:ref:`api-overview`.
-
-.. _api-format:
-
-Request Format and Responses
-============================
-
-CouchDB supports the following HTTP request methods:
-
--  ``GET``
-
-   Request the specified item. As with normal HTTP requests, the format
-   of the URL defines what is returned. With CouchDB this can include
-   static items, database documents, and configuration and statistical
-   information. In most cases the information is returned in the form of
-   a JSON document.
-
--  ``HEAD``
-
-   The ``HEAD`` method is used to get the HTTP header of a ``GET``
-   request without the body of the response.
-
--  ``POST``
-
-   Upload data. Within CouchDB ``POST`` is used to set values, including
-   uploading documents, setting document values, and starting certain
-   administration commands.
-
--  ``PUT``
-
-   Used to put a specified resource. In CouchDB ``PUT`` is used to
-   create new objects, including databases, documents, views and design
-   documents.
-
--  ``DELETE``
-
-   Deletes the specified resource, including documents, views, and
-   design documents.
-
--  ``COPY``
-
-   A special method that can be used to copy documents and objects.
-
-If you use the an unsupported HTTP request type with a URL that does not
-support the specified type, a 405 error will be returned, listing the
-supported HTTP methods. For example:
-
-.. code-block:: javascript
-
-    {
-        "error":"method_not_allowed",
-        "reason":"Only GET,HEAD allowed"
-    }
-          
-
-The CouchDB design document API and the functions when returning HTML
-(for example as part of a show or list) enables you to include custom
-HTTP headers through the ``headers`` block of the return object.
-
-HTTP Headers
-============
-
-Because CouchDB uses HTTP for all communication, you need to ensure that
-the correct HTTP headers are supplied (and processed on retrieval) so
-that you get the right format and encoding. Different environments and
-clients will be more or less strict on the effect of these HTTP headers
-(especially when not present). Where possible you should be as specific
-as possible.
-
-Request Headers
----------------
-
--  ``Content-type``
-
-   Specifies the content type of the information being supplied within
-   the request. The specification uses MIME type specifications. For the
-   majority of requests this will be JSON (``application/json``). For
-   some settings the MIME type will be plain text. When uploading
-   attachments it should be the corresponding MIME type for the
-   attachment or binary (``application/octet-stream``).
-
-   The use of the ``Content-type`` on a request is highly recommended.
-
--  ``Accept``
-
-   Specifies the list of accepted data types to be returned by the
-   server (i.e. that are accepted/understandable by the client). The
-   format should be a list of one or more MIME types, separated by
-   colons.
-
-   For the majority of requests the definition should be for JSON data
-   (``application/json``). For attachments you can either specify the
-   MIME type explicitly, or use ``*/*`` to specify that all file types
-   are supported. If the ``Accept`` header is not supplied, then the
-   ``*/*`` MIME type is assumed (i.e. client accepts all formats).
-
-   The use of ``Accept`` in queries for CouchDB is not required, but is
-   highly recommended as it helps to ensure that the data returned can
-   be processed by the client.
-
-   If you specify a data type using the ``Accept`` header, CouchDB will
-   honor the specified type in the ``Content-type`` header field
-   returned. For example, if you explicitly request ``application/json``
-   in the ``Accept`` of a request, the returned HTTP headers will use
-   the value in the returned ``Content-type`` field.
-
-   For example, when sending a request without an explicit ``Accept``
-   header, or when specifying ``*/*``:
-
-   .. code-block:: http
-
-       GET /recipes HTTP/1.1
-       Host: couchdb:5984
-       Accept: */*
-
-   The returned headers are:
-
-   .. code-block:: http
-
-       Server: CouchDB/1.0.1 (Erlang OTP/R13B)
-       Date: Thu, 13 Jan 2011 13:39:34 GMT
-       Content-Type: text/plain;charset=utf-8
-       Content-Length: 227
-       Cache-Control: must-revalidate
-
-   Note that the returned content type is ``text/plain`` even though the
-   information returned by the request is in JSON format.
-
-   Explicitly specifying the ``Accept`` header:
-
-   .. code-block:: http
-
-       GET /recipes HTTP/1.1
-       Host: couchdb:5984
-       Accept: application/json
-
-   The headers returned include the ``application/json`` content type:
-
-   .. code-block:: http
-
-       Server: CouchDB/|version| (Erlang OTP/R13B)
-       Date: Thu, 13 Jan 2011 13:40:11 GMT
-       Content-Type: application/json
-       Content-Length: 227
-       Cache-Control: must-revalidate
-
-Response Headers
-----------------
-
-Response headers are returned by the server when sending back content
-and include a number of different header fields, many of which are
-standard HTTP response header and have no significance to CouchDB
-operation. The list of response headers important to CouchDB are listed
-below.
-
--  ``Content-type``
-
-   Specifies the MIME type of the returned data. For most request, the
-   returned MIME type is ``text/plain``. All text is encoded in Unicode
-   (UTF-8), and this is explicitly stated in the returned
-   ``Content-type``, as ``text/plain;charset=utf-8``.
-
--  ``Cache-control``
-
-   The cache control HTTP response header provides a suggestion for
-   client caching mechanisms on how to treat the returned information.
-   CouchDB typically returns the ``must-revalidate``, which indicates
-   that the information should be revalidated if possible. This is used
-   to ensure that the dynamic nature of the content is correctly
-   updated.
-
--  ``Content-length``
-
-   The length (in bytes) of the returned content.
-
--  ``Etag``
-
-   The ``Etag`` HTTP header field is used to show the revision for a
-   document, or a view.
-
-   ETags have been assigned to a map/reduce group (the collection of
-   views in a single design document). Any change to any of the indexes
-   for those views would generate a new ETag for all view URL's in a
-   single design doc, even if that specific view's results had not
-   changed.
-
-   Each ``_view`` URL has its own ETag which only gets updated when
-   changes are made to the database that effect that index. If the
-   index for that specific view does not change, that view keeps the
-   original ETag head (therefore sending back 304 Not Modified more
-   often).
-
-.. _json:
-
-JSON Basics
-===========
-
-The majority of requests and responses to CouchDB use the JavaScript
-Object Notation (JSON) for formatting the content and structure of the
-data and responses.
-
-JSON is used because it is the simplest and easiest to use solution for
-working with data within a web browser, as JSON structures can be
-evaluated and used as JavaScript objects within the web browser
-environment. JSON also integrates with the server-side JavaScript used
-within CouchDB.
-
-JSON supports the same basic types as supported by JavaScript, these
-are:
-
--  Number (either integer or floating-point).
-
--  String; this should be enclosed by double-quotes and supports Unicode
-   characters and backslash escaping. For example:
-
-   .. code-block:: javascript
-
-       "A String"
-
--  Boolean - a ``true`` or ``false`` value. You can use these strings
-   directly. For example:
-
-   .. code-block:: javascript
-
-       { "value": true}
-
--  Array - a list of values enclosed in square brackets. For example:
-
-   .. code-block:: javascript
-
-       ["one", "two", "three"]
-
--  Object - a set of key/value pairs (i.e. an associative array, or
-   hash). The key must be a string, but the value can be any of the
-   supported JSON values. For example:
-
-   .. code-block:: javascript
-
-       {
-          "servings" : 4,
-          "subtitle" : "Easy to make in advance, and then cook when ready",
-          "cooktime" : 60,
-          "title" : "Chicken Coriander"
-       }
-           
-
-   In CouchDB, the JSON object is used to represent a variety of
-   structures, including the main CouchDB document.
-
-Parsing JSON into a JavaScript object is supported through the
-``JSON.parse()`` function in JavaScript, or through various libraries that
-will perform the parsing of the content into a JavaScript object for
-you. Libraries for parsing and generating JSON are available in many
-languages, including Perl, Python, Ruby, Erlang and others.
-
-.. warning::
-   Care should be taken to ensure that your JSON structures are
-   valid, invalid structures will cause CouchDB to return an HTTP status code
-   of 500 (server error).
-
-.. _errors:
-
-HTTP Status Codes
-=================
-
-With the interface to CouchDB working through HTTP, error codes and
-statuses are reported using a combination of the HTTP status code
-number, and corresponding data in the body of the response data.
-
-A list of the error codes returned by CouchDB, and generic descriptions
-of the related errors are provided below. The meaning of different
-status codes for specific request types are provided in the
-corresponding API call reference.
-
--  ``200 - OK``
-
-   Request completed successfully.
-
--  ``201 - Created``
-
-   Document created successfully.
-
--  ``202 - Accepted``
-
-   Request has been accepted, but the corresponding operation may not
-   have completed. This is used for background operations, such as
-   database compaction.
-
--  ``304 - Not Modified``
-
-   The additional content requested has not been modified. This is used
-   with the ETag system to identify the version of information returned.
-
--  ``400 - Bad Request``
-
-   Bad request structure. The error can indicate an error with the
-   request URL, path or headers. Differences in the supplied MD5 hash
-   and content also trigger this error, as this may indicate message
-   corruption.
-
--  ``401 - Unauthorized``
-
-   The item requested was not available using the supplied
-   authorization, or authorization was not supplied.
-
--  ``403 - Forbidden``
-
-   The requested item or operation is forbidden.
-
--  ``404 - Not Found``
-
-   The requested content could not be found. The content will include
-   further information, as a JSON object, if available. The structure
-   will contain two keys, ``error`` and ``reason``. For example:
-
-   .. code-block:: javascript
-
-       {"error":"not_found","reason":"no_db_file"}
-
--  ``405 - Resource Not Allowed``
-
-   A request was made using an invalid HTTP request type for the URL
-   requested. For example, you have requested a ``PUT`` when a ``POST``
-   is required. Errors of this type can also triggered by invalid URL
-   strings.
-
--  ``406 - Not Acceptable``
-
-   The requested content type is not supported by the server.
-
--  ``409 - Conflict``
-
-   Request resulted in an update conflict.
-
--  ``412 - Precondition Failed``
-
-   The request headers from the client and the capabilities of the
-   server do not match.
-
--  ``415 - Bad Content Type``
-
-   The content types supported, and the content type of the information
-   being requested or submitted indicate that the content type is not
-   supported.
-
--  ``416 - Requested Range Not Satisfiable``
-
-   The range specified in the request header cannot be satisfied by the
-   server.
-
--  ``417 - Expectation Failed``
-
-   When sending documents in bulk, the bulk load operation failed.
-
--  ``500 - Internal Server Error``
-
-   The request was invalid, either because the supplied JSON was
-   invalid, or invalid information was supplied as part of the request.
-
-.. _api-overview:
-
-CouchDB API Overview
-====================
-
-The components of the API URL path help determine the part of the
-CouchDB server that is being accessed. The result is the structure of
-the URL request both identifies and effectively describes the area of
-the database you are accessing.
-
-As with all URLs, the individual components are separated by a forward
-slash.
-
-As a general rule, URL components and JSON fields starting with the
-``_`` (underscore) character represent a special component or entity
-within the server or returned object. For example, the URL fragment
-``/_all_dbs`` gets a list of all of the databases in a CouchDB instance.
-
-The remainder of the URL API structure can be divided up according to
-the URL structure. The different sections are divided as follows:
-
--  ``/db``
-
-   Database methods, related to adding, updating or deleting databases,
-   and setting database parameters and operations. For more detailed
-   information, see :ref:`api-db`.
-
--  ``/db/doc``
-
-   Document methods, those that create, store, update or delete CouchDB
-   documents and their attachments. For more information, see :ref:`api-doc`.
-
--  ``/db/_local/local-doc``
-
-   Document methods, those that create, store, update or delete CouchDB
-   documents only within the local database. Local documents are not
-   synchronized with other databases. For more information, see
-   :ref:`api-local`.
-
--  ``/db/_design/design-doc``
-
-   Design documents provide the methods and structure for recovering
-   information from a CouchDB database in the form of views, shows and
-   lists. For more information, see :ref:`api-design`.
-
--  ``/_special``
-
-   Special methods that obtain or set information about the CouchDB
-   instance, including methods for configuring replication, accessing
-   the logs, and generate Universally Unique IDs (UUIDs). For more
-   information, see :ref:`api-misc`.
-
--  ``/_config``
-
-   Methods for getting, and settings, CouchDB configuration parameters.
-   For more information, see :ref:`api-config`.

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/api/authn.rst
----------------------------------------------------------------------
diff --git a/share/docs/rst/api/authn.rst b/share/docs/rst/api/authn.rst
deleted file mode 100644
index 66dd7f2..0000000
--- a/share/docs/rst/api/authn.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-======================
-Authentication Methods
-======================
-
-.. todo:: Authentication Methods
-
-The CouchDB Authentication methods provide an interface for obtaining
-session and authorization data.
-
-A list of the available methods and URL paths are provided below:
-
-+--------+-------------------------+-------------------------------------------+
-| Method | Path                    | Description                               |
-+========+=========================+===========================================+
-| GET    | /_oauth/access_token    | TBC                                       |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /_oauth/authorize       | TBC                                       |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /_oauth/authorize       | TBC                                       |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /_oauth/request_token   | TBC                                       |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /_session               | Returns cookie based login user           |
-|        |                         | information                               |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /_session               | Do cookie based user login                |
-+--------+-------------------------+-------------------------------------------+
-| DELETE | /_session               | Logout cookie based user                  |
-+--------+-------------------------+-------------------------------------------+

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/api/configuration.rst
----------------------------------------------------------------------
diff --git a/share/docs/rst/api/configuration.rst b/share/docs/rst/api/configuration.rst
deleted file mode 100644
index a57e5d2..0000000
--- a/share/docs/rst/api/configuration.rst
+++ /dev/null
@@ -1,285 +0,0 @@
-.. _api-config:
-
-=====================
-Configuration Methods
-=====================
-
-The CouchDB API Server Configuration Methods provide an interface to
-query and update the various configuration values within a running
-CouchDB instance.
-
-A list of the available methods and URL paths are provided below:
-
-+--------+-------------------------+-------------------------------------------+
-| Method | Path                    | Description                               |
-+========+=========================+===========================================+
-| GET    | /_config                | Obtain a list of the entire server        |
-|        |                         | configuration                             |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /_config/section        | Get all the configuration values for the  |
-|        |                         | specified section                         |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /_config/section/key    | Get a specific section/configuration value|
-+--------+-------------------------+-------------------------------------------+
-| PUT    | /_config/section/key    | Set the specified configuration value     |
-+--------+-------------------------+-------------------------------------------+
-| DELETE | /_config/section/key    | Delete the current setting                |
-+--------+-------------------------+-------------------------------------------+
-
-``GET /_config``
-================
-
-* **Method**: ``GET /_config``
-* **Request**: None
-* **Response**: Returns a structure configuration name and value pairs,
-  organized by section
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **200**:
-    Request completed successfully.
-
-Returns the entire CouchDB server configuration as a JSON structure. The
-structure is organized by different configuration sections, with
-individual values.
-
-For example, to get the configuration for a server:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/_config
-    Accept: application/json
-
-The response is the JSON structure:
-
-.. code-block:: javascript
-
-    {
-       "query_server_config" : {
-          "reduce_limit" : "true"
-       },
-       "couchdb" : {
-          "os_process_timeout" : "5000",
-          "max_attachment_chunk_size" : "4294967296",
-          "max_document_size" : "4294967296",
-          "uri_file" : "/var/lib/couchdb/couch.uri",
-          "max_dbs_open" : "100",
-          "view_index_dir" : "/var/lib/couchdb",
-          "util_driver_dir" : "/usr/lib64/couchdb/erlang/lib/couch-1.0.1/priv/lib",
-          "database_dir" : "/var/lib/couchdb",
-          "delayed_commits" : "true"
-       },
-       "attachments" : {
-          "compressible_types" : "text/*, application/javascript, application/json,  application/xml",
-          "compression_level" : "8"
-       },
-       "uuids" : {
-          "algorithm" : "utc_random"
-       },
-       "daemons" : {
-          "view_manager" : "{couch_view, start_link, []}",
-          "auth_cache" : "{couch_auth_cache, start_link, []}",
-          "uuids" : "{couch_uuids, start, []}",
-          "stats_aggregator" : "{couch_stats_aggregator, start, []}",
-          "query_servers" : "{couch_query_servers, start_link, []}",
-          "httpd" : "{couch_httpd, start_link, []}",
-          "stats_collector" : "{couch_stats_collector, start, []}",
-          "db_update_notifier" : "{couch_db_update_notifier_sup, start_link, []}",
-          "external_manager" : "{couch_external_manager, start_link, []}"
-       },
-       "stats" : {
-          "samples" : "[0, 60, 300, 900]",
-          "rate" : "1000"
-       },
-       "httpd" : {
-          "vhost_global_handlers" : "_utils, _uuids, _session, _oauth, _users",
-          "secure_rewrites" : "true",
-          "authentication_handlers" : "{couch_httpd_oauth, oauth_authentication_handler},
-                                       {couch_httpd_auth, cookie_authentication_handler},
-                                       {couch_httpd_auth, default_authentication_handler}",
-          "port" : "5984",
-          "default_handler" : "{couch_httpd_db, handle_request}",
-          "allow_jsonp" : "false",
-          "bind_address" : "192.168.0.2",
-          "max_connections" : "2048"
-       },
-       "query_servers" : {
-          "javascript" : "/usr/bin/couchjs /usr/share/couchdb/server/main.js"
-       },
-       "couch_httpd_auth" : {
-          "authentication_db" : "_users",
-          "require_valid_user" : "false",
-          "authentication_redirect" : "/_utils/session.html",
-          "timeout" : "600",
-          "auth_cache_size" : "50"
-       },
-       "httpd_db_handlers" : {
-          "_design" : "{couch_httpd_db, handle_design_req}",
-          "_compact" : "{couch_httpd_db, handle_compact_req}",
-          "_view_cleanup" : "{couch_httpd_db, handle_view_cleanup_req}",
-          "_temp_view" : "{couch_httpd_view, handle_temp_view_req}",
-          "_changes" : "{couch_httpd_db, handle_changes_req}"
-       },
-       "replicator" : {
-          "max_http_sessions" : "10",
-          "max_http_pipeline_size" : "10"
-       },
-       "log" : {
-          "include_sasl" : "true",
-          "level" : "info",
-          "file" : "/var/log/couchdb/couch.log"
-       },
-       "httpd_design_handlers" : {
-          "_update" : "{couch_httpd_show, handle_doc_update_req}",
-          "_show" : "{couch_httpd_show, handle_doc_show_req}",
-          "_info" : "{couch_httpd_db,   handle_design_info_req}",
-          "_list" : "{couch_httpd_show, handle_view_list_req}",
-          "_view" : "{couch_httpd_view, handle_view_req}",
-          "_rewrite" : "{couch_httpd_rewrite, handle_rewrite_req}"
-       },
-       "httpd_global_handlers" : {
-          "_replicate" : "{couch_httpd_misc_handlers, handle_replicate_req}",
-          "/" : "{couch_httpd_misc_handlers, handle_welcome_req, <<\"Welcome\">>}",
-          "_config" : "{couch_httpd_misc_handlers, handle_config_req}",
-          "_utils" : "{couch_httpd_misc_handlers, handle_utils_dir_req, \"/usr/share/couchdb/www\"}",
-          "_active_tasks" : "{couch_httpd_misc_handlers, handle_task_status_req}",
-          "_session" : "{couch_httpd_auth, handle_session_req}",
-          "_log" : "{couch_httpd_misc_handlers, handle_log_req}",
-          "favicon.ico" : "{couch_httpd_misc_handlers, handle_favicon_req, \"/usr/share/couchdb/www\"}",
-          "_all_dbs" : "{couch_httpd_misc_handlers, handle_all_dbs_req}",
-          "_oauth" : "{couch_httpd_oauth, handle_oauth_req}",
-          "_restart" : "{couch_httpd_misc_handlers, handle_restart_req}",
-          "_uuids" : "{couch_httpd_misc_handlers, handle_uuids_req}",
-          "_stats" : "{couch_httpd_stats_handlers, handle_stats_req}"
-       }
-    }
-        
-
-``GET /_config/section``
-========================
-
-* **Method**: ``GET /_config/section``
-* **Request**: None
-* **Response**: All the configuration values within a specified section
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **200**:
-    Request completed successfully.
-
-Gets the configuration structure for a single section. For example, to
-retrieve the CouchDB configuration section values:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/_config/couchdb
-    Accept: application/json
-
-The returned JSON contains just the configuration values for this
-section:
-
-.. code-block:: javascript
-
-    {
-       "os_process_timeout" : "5000",
-       "max_attachment_chunk_size" : "4294967296",
-       "max_document_size" : "4294967296",
-       "uri_file" : "/var/lib/couchdb/couch.uri",
-       "max_dbs_open" : "100",
-       "view_index_dir" : "/var/lib/couchdb",
-       "util_driver_dir" : "/usr/lib64/couchdb/erlang/lib/couch-1.0.1/priv/lib",
-       "database_dir" : "/var/lib/couchdb",
-       "delayed_commits" : "true"
-    }
-
-``GET /_config/section/key``
-============================
-
-* **Method**: ``GET /_config/section/key``
-* **Request**: None
-* **Response**: Value of the specified key/section
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **200**:
-    Request completed successfully.
-
-Gets a single configuration value from within a specific configuration
-section. For example, to obtain the current log level:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/_config/log/level
-    Accept: application/json
-
-Returns the string of the log level:
-
-.. code-block:: javascript
-
-    "info"
-
-.. note::
-   The returned value will be the JSON of the value, which may be a
-   string or numeric value, or an array or object. Some client
-   environments may not parse simple strings or numeric values as valid JSON.
-
-.. _api-put-config:
-
-``PUT /_config/section/key``
-============================
-
-* **Method**: ``PUT /_config/section/key``
-* **Request**: Value structure
-* **Response**: Previous value
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **200**:
-    Configuration option updated successfully
-
-  * **500**:
-    Error setting configuration
-
-Updates a configuration value. The new value should be supplied in the
-request body in the corresponding JSON format. For example, if you are
-setting a string value, you must supply a valid JSON string.
-
-For example, to set the function used to generate UUIDs by the
-``GET /_uuids`` API call to use the ``utc_random`` generator:
-
-.. code-block:: http
-
-    PUT http://couchdb:5984/_config/uuids/algorithm
-    Content-Type: application/json
-
-    "utc_random"
-
-The return value will be empty, with the response code indicating the
-success or failure of the configuration setting.
-
-``DELETE /_config/section/key``
-===============================
-
-* **Method**: ``DELETE /_config/section/key``
-* **Request**: None
-* **Response**: Previous value
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **409**:
-    Supplied revision is incorrect or missing
-
-Deletes a configuration value. The returned JSON will be the value of
-the configuration parameter before it was deleted. For example, to
-delete the UUID parameter:
-
-.. code-block:: http
-
-    DELETE http://couchdb:5984/_config/uuids/algorithm
-    Content-Type: application/json
-
-The returned value is the last configured UUID function:
-
-.. code-block:: javascript
-
-    "random"

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/api/database.rst
----------------------------------------------------------------------
diff --git a/share/docs/rst/api/database.rst b/share/docs/rst/api/database.rst
deleted file mode 100644
index becc7d5..0000000
--- a/share/docs/rst/api/database.rst
+++ /dev/null
@@ -1,1451 +0,0 @@
-.. _api-db:
-
-================
-Database Methods
-================
-
-The Database methods provide an interface to an entire database withing
-CouchDB. These are database, rather than document, level requests.
-
-A list of the available methods and URL paths are provided below:
-
-+--------+-------------------------+-------------------------------------------+
-| Method | Path                    | Description                               |
-+========+=========================+===========================================+
-| GET    | /db                     | Returns database information              |
-+--------+-------------------------+-------------------------------------------+
-| PUT    | /db                     | Create a new database                     |
-+--------+-------------------------+-------------------------------------------+
-| DELETE | /db                     | Delete an existing database               |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /db/_all_docs           | Returns a built-in view of all documents  |
-|        |                         | in this database                          |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_all_docs           | Returns certain rows from the built-in    |
-|        |                         | view of all documents                     |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_bulk_docs          | Insert multiple documents in to the       |
-|        |                         | database in a single request              |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /db/_changes            | Returns changes for the given database    |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_compact            | Starts a compaction for the database      |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_compact/design-doc | Starts a compaction for all the views in  |
-|        |                         | the selected design document              |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_ensure_full_commit | Makes sure all uncommitted changes are    |
-|        |                         | written and synchronized to the disk      |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_missing_revs       | Given a list of document revisions,       |
-|        |                         | returns the document revisions that do not|
-|        |                         | exist in the database                     |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_purge              | Purge some historical documents entirely  |
-|        |                         | from database history                     |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_revs_diff          | Given a list of document revisions,       |
-|        |                         | returns differences between the given     |
-|        |                         | revisions and ones that are in the        |
-|        |                         | database                                  |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /db/_revs_limit         | Gets the limit of historical revisions to |
-|        |                         | store for a single document in the        |
-|        |                         | database                                  |
-+--------+-------------------------+-------------------------------------------+
-| PUT    | /db/_revs_limit         | Sets the limit of historical revisions to |
-|        |                         | store for a single document in the        |
-|        |                         | database                                  |
-+--------+-------------------------+-------------------------------------------+
-| GET    | /db/_security           | Returns the special security object for   |
-|        |                         | the database                              |
-+--------+-------------------------+-------------------------------------------+
-| PUT    | /db/_security           | Sets the special security object for the  |
-|        |                         | database                                  |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_temp_view          | Execute a given view function for all     |
-|        |                         | documents and return the result           |
-+--------+-------------------------+-------------------------------------------+
-| POST   | /db/_view_cleanup       | Removes view files that are not used by   |
-|        |                         | any design document                       |
-+--------+-------------------------+-------------------------------------------+
-
-For all the database methods, the database name within the URL path
-should be the database name that you wish to perform the operation on.
-For example, to obtain the meta information for the database
-``recipes``, you would use the HTTP request:
-
-.. code-block:: http
-
-    GET /recipes
-
-For clarity, the form below is used in the URL paths:
-
-.. code-block:: http
-
-    GET /db
-
-Where ``db`` is the name of any database.
-
-.. _api-get-db:
-
-``GET /db``
-===========
-
-* **Method**: ``GET /db``
-* **Request**: None
-* **Response**: Information about the database in JSON format
-* **Admin Privileges Required**: no
-* **Return Codes**:
-
-  * **404**:
-    The requested content could not be found. The returned content will include
-    further information, as a JSON object, if available.
-
-Gets information about the specified database. For example, to retrieve
-the information for the database ``recipe``:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/recipes
-    Accept: application/json
-
-The JSON response contains meta information about the database. A sample
-of the JSON returned for an empty database is provided below:
-
-.. code-block:: javascript
-
-    {
-       "compact_running" : false,
-       "committed_update_seq" : 375048,
-       "disk_format_version" : 5,
-       "disk_size" : 33153123,
-       "doc_count" : 18386,
-       "doc_del_count" : 0,
-       "db_name" : "recipes",
-       "instance_start_time" : "1290700340925570",
-       "purge_seq" : 10,
-       "update_seq" : 375048
-    }
-        
-
-The elements of the returned structure are shown in the table below:
-
-+----------------------------------+-------------------------------------------+
-| Field                            | Description                               |
-+==================================+===========================================+
-| committed_update_seq             | The number of committed update.           |
-+----------------------------------+-------------------------------------------+
-| compact_running                  | Set to true if the database compaction    |
-|                                  | routine is operating on this database.    |
-+----------------------------------+-------------------------------------------+
-| db_name                          | The name of the database.                 |
-+----------------------------------+-------------------------------------------+
-| disk_format_version              | The version of the physical format used   |
-|                                  | for the data when it is stored on disk.   |
-+----------------------------------+-------------------------------------------+
-| disk_size                        | Size in bytes of the data as stored on the|
-|                                  | disk. Views indexes are not included in   |
-|                                  | the calculation.                          |
-+----------------------------------+-------------------------------------------+
-| doc_count                        | A count of the documents in the specified |
-|                                  | database.                                 |
-+----------------------------------+-------------------------------------------+
-| doc_del_count                    | Number of deleted documents               |
-+----------------------------------+-------------------------------------------+
-| instance_start_time              | Timestamp of when the database was        |
-|                                  | created, expressed in milliseconds since  |
-|                                  | the epoch.                                |
-+----------------------------------+-------------------------------------------+
-| purge_seq                        | The number of purge operations on the     |
-|                                  | database.                                 |
-+----------------------------------+-------------------------------------------+
-| update_seq                       | The current number of updates to the      |
-|                                  | database.                                 |
-+----------------------------------+-------------------------------------------+
-
-``PUT /db``
-===========
-
-* **Method**: ``PUT /db``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: no
-* **Return Codes**:
-
-  * **400**:
-    Invalid database name
-
-  * **412**:
-    Database already exists
-
-Creates a new database. The database name must be composed of one or
-more of the following characters:
-
--  Lowercase characters (``a-z``)
-
--  Name must begin with a lowercase letter
-
--  Digits (``0-9``)
-
--  Any of the characters ``_``, ``$``, ``(``, ``)``, ``+``, ``-``, and
-   ``/``.
-
-Trying to create a database that does not meet these requirements will
-return an error quoting these restrictions.
-
-To create the database ``recipes``:
-
-.. code-block:: http
-
-    PUT http://couchdb:5984/recipes
-    Content-Type: application/json
-
-The returned content contains the JSON status:
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-
-Anything should be treated as an error, and the problem should be taken
-form the HTTP response code.
-
-``DELETE /db``
-==============
-
-* **Method**: ``DELETE /db``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: no
-* **Return Codes**:
-
-  * **200**:
-    Database has been deleted
-
-  * **404**:
-    The requested content could not be found. The returned content will include
-    further information, as a JSON object, if available.
-
-Deletes the specified database, and all the documents and attachments
-contained within it.
-
-To delete the database ``recipes`` you would send the request:
-
-.. code-block:: http
-
-    DELETE http://couchdb:5984/recipes
-    Content-Type: application/json
-
-If successful, the returned JSON will indicate success
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-
-.. _api-changes:
-
-``GET /db/_changes``
-====================
-
-* **Method**: ``GET /db/_changes``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: no
-* **Query Arguments**:
-
-  * **Argument**: doc_ids
-
-    * **Description**:  Specify the list of documents IDs to be filtered
-    * **Optional**: yes
-    * **Type**: json
-    * **Default**: none
-
-  * **Argument**: feed
-
-    * **Description**:  Type of feed
-    * **Optional**: yes
-    * **Type**: string
-    * **Default**: normal
-    * **Supported Values**:
-
-      * **continuous**: Continuous (non-polling) mode
-      * **longpoll**: Long polling mode
-      * **normal**: Normal mode
-
-  * **Argument**: filter
-
-    * **Description**:  Filter function from a design document to get updates
-    * **Optional**: yes
-    * **Type**: string
-    * **Default**: none
-    * **Supported Values**:
-
-  * **Argument**: heartbeat
-
-    * **Description**:  Period after which an empty line is sent during longpoll
-      or continuous
-    * **Optional**: yes
-    * **Type**: numeric
-    * **Default**: 60000
-    * **Quantity**: milliseconds
-
-  * **Argument**: include_docs
-
-    * **Description**:  Include the document with the result
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: false
-
-  * **Argument**: limit
-
-    * **Description**:  Maximum number of rows rows to return
-    * **Optional**: yes
-    * **Type**: numeric
-    * **Default**: none
-
-  * **Argument**: since
-
-    * **Description**:  Start the results from changes immediately after the
-      specified sequence number
-    * **Optional**: yes
-    * **Type**: numeric
-    * **Default**: 0
-
-Obtains a list of the changes made to the database. This can be used to
-monitor for update and modifications to the database for post processing
-or synchronization. There are three different types of supported changes
-feeds, poll, longpoll, and continuous. All requests are poll requests by
-default. You can select any feed type explicitly using the ``feed``
-query argument.
-
--  **Poll**
-
-   With polling you can request the changes that have occured since a
-   specific sequence number. This returns the JSON structure containing
-   the changed document information. When you perform a poll change
-   request, only the changes since the specific sequence number are
-   returned. For example, the query
-
-   .. code-block:: http
-
-       DELETE http://couchdb:5984/recipes/_changes
-       Content-Type: application/json
-
-   Will get all of the changes in the database. You can request a
-   starting point using the ``since`` query argument and specifying the
-   sequence number. You will need to record the latest sequence number
-   in your client and then use this when making another request as the
-   new value to the ``since`` parameter.
-
--  **Longpoll**
-
-   With long polling the request to the server will remain open until a
-   change is made on the database, when the changes will be reported,
-   and then the connection will close. The long poll is useful when you
-   want to monitor for changes for a specific purpose without wanting to
-   monitoring continuously for changes.
-
-   Because the wait for a change can be significant you can set a
-   timeout before the connection is automatically closed (the
-   ``timeout`` argument). You can also set a heartbeat interval (using
-   the ``heartbeat`` query argument), which sends a newline to keep the
-   connection open.
-
--  **Continuous**
-
-   Continuous sends all new changes back to the client immediately,
-   without closing the connection. In continuous mode the format of the
-   changes is slightly different to accommodate the continuous nature
-   while ensuring that the JSON output is still valid for each change
-   notification.
-
-   As with the longpoll feed type you can set both the timeout and
-   heartbeat intervals to ensure that the connection is kept open for
-   new changes and updates.
-
-The return structure for ``normal`` and ``longpoll`` modes is a JSON
-array of changes objects, and the last update sequence number. The
-structure is described in the following table.
-
-+----------------------------------+-------------------------------------------+
-| Field                            | Description                               |
-+==================================+===========================================+
-| last_seq                         | Last change sequence number.              |
-+----------------------------------+-------------------------------------------+
-| results [array]                  | Changes made to a database                |
-+----------------------------------+-------------------------------------------+
-|         changes [array]          | List of changes, field-by-field, for this |
-|                                  | document                                  |
-+----------------------------------+-------------------------------------------+
-|         id                       | Document ID                               |
-+----------------------------------+-------------------------------------------+
-|         seq                      | Update sequence number                    |
-+----------------------------------+-------------------------------------------+
-
-The return format for ``continuous`` mode the server sends a ``CRLF``
-(carriage-return, linefeed) delimited line for each change. Each line
-contains the `JSON object`_.
-
-You can also request the full contents of each document change (instead
-of just the change notification) by using the ``include_docs``
-parameter.
-
-Filtering
----------
-
-You can filter the contents of the changes feed in a number of ways. The
-most basic way is to specify one or more document IDs to the query. This
-causes the returned structure value to only contain changes for the
-specified IDs. Note that the value of this query argument should be a
-JSON formatted array.
-
-You can also filter the ``_changes`` feed by defining a filter function
-within a design document. The specification for the filter is the same
-as for replication filters. You specify the name of the filter function
-to the ``filter`` parameter, specifying the design document name and
-filter name. For example:
-
-.. code-block:: http
-
-    GET /db/_changes?filter=design_doc/filtername
-
-The ``_changes`` feed can be used to watch changes to specific document
-ID's or the list of ``_design`` documents in a database. If the
-``filters`` parameter is set to ``_doc_ids`` a list of doc IDs can be
-passed in the ``doc_ids`` parameter as a JSON array. For more
-information, see :ref:`changes`.
-
-.. _api-compact:
-
-``POST /db/_compact``
-=====================
-
-* **Method**: ``POST /db/_compact``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **202**:
-    Compaction request has been accepted
-
-  * **404**:
-    The requested content could not be found. The returned content will include
-    further information, as a JSON object, if available.
-
-Request compaction of the specified database. Compaction compresses the
-disk database file by performing the following operations:
-
--  Writes a new version of the database file, removing any unused
-   sections from the new version during write. Because a new file is
-   temporary created for this purpose, you will need twice the current
-   storage space of the specified database in order for the compaction
-   routine to complete.
-
--  Removes old revisions of documents from the database, up to the
-   per-database limit specified by the ``_revs_limit`` database
-   parameter. See :ref:`api-get-db`.
-
-Compaction can only be requested on an individual database; you cannot
-compact all the databases for a CouchDB instance. The compaction process
-runs as a background process.
-
-You can determine if the compaction process is operating on a database
-by obtaining the database meta information, the ``compact_running``
-value of the returned database structure will be set to true. See
-:ref:`api-get-db`.
-
-You can also obtain a list of running processes to determine whether
-compaction is currently running. See :ref:`active-tasks`.
-
-.. _api-compact-ddoc:
-
-``POST /db/_compact/design-doc``
-================================
-
-* **Method**: ``POST /db/_compact/design-doc``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: yes
-* **Return Codes**:
-
-  * **202**:
-    Compaction request has been accepted
-
-  * **404**:
-    The requested content could not be found. The returned content will include
-    further information, as a JSON object, if available.
-
-Compacts the view indexes associated with the specified design document.
-You can use this in place of the full database compaction if you know a
-specific set of view indexes have been affected by a recent database
-change.
-
-For example, to compact the views associated with the ``recipes`` design
-document:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_compact/recipes
-    Content-Type: application/json
-
-CouchDB will immediately return with a status indicating that the
-compaction request has been received (HTTP status code 202):
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-        
-
-``POST /db/_view_cleanup``
-==========================
-
-* **Method**: ``POST /db/_view_cleanup``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: yes
-
-Cleans up the cached view output on disk for a given view. For example:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_view_cleanup
-    Content-Type: application/json
-
-If the request is successful, a basic status message us returned:
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-        
-
-``POST /db/_ensure_full_commit``
-================================
-
-* **Method**: ``POST /db/_ensure_full_commit``
-* **Request**: None
-* **Response**: JSON success statement
-* **Admin Privileges Required**: no
-* **Return Codes**:
-
-  * **202**:
-    Commit completed successfully
-
-  * **404**:
-    The requested content could not be found. The returned content will include
-    further information, as a JSON object, if available.
-
-
-Commits any recent changes to the specified database to disk. You should
-call this if you want to ensure that recent changes have been written.
-For example, to commit all the changes to disk for the database
-``recipes`` you would use:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_ensure_full_commit
-    Content-Type: application/json
-
-This returns a status message, containing the success message and the
-timestamp for when the CouchDB instance was started:
-
-.. code-block:: javascript
-
-    {
-      "ok" : true,
-      "instance_start_time" : "1288186189373361"
-    }
-
-``POST /db/_bulk_docs``
-=======================
-
-* **Method**: ``POST /db/_bulk_docs``
-* **Request**: JSON of the docs and updates to be applied
-* **Response**: JSON success statement
-* **Admin Privileges Required**: no
-* **Return Codes**:
-
-  * **201**:
-    Document(s) have been created or updated
-
-The bulk document API allows you to create and update multiple documents
-at the same time within a single request. The basic operation is similar
-to creating or updating a single document, except that you batch the
-document structure and information and . When creating new documents the
-document ID is optional. For updating existing documents, you must
-provide the document ID, revision information, and new document values.
-
-For both inserts and updates the basic structure of the JSON is the
-same:
-
-+----------------------------------+-------------------------------------------+
-| Field                            | Description                               |
-+==================================+===========================================+
-| all_or_nothing (optional)        | Sets the database commit mode to use      |
-|                                  | all-or-nothing semantics                  |
-+----------------------------------+-------------------------------------------+
-| docs [array]                     | Bulk Documents Document                   |
-+----------------------------------+-------------------------------------------+
-|         _id (optional)           | List of changes, field-by-field, for this |
-|                                  | document                                  |
-+----------------------------------+-------------------------------------------+
-|         _rev (optional)          | Document ID                               |
-+----------------------------------+-------------------------------------------+
-|         _deleted (optional)      | Update sequence number                    |
-+----------------------------------+-------------------------------------------+
-
-Inserting Documents in Bulk
----------------------------
-
-To insert documents in bulk into a database you need to supply a JSON
-structure with the array of documents that you want to add to the
-database. Using this method you can either include a document ID, or
-allow the document ID to be automatically generated.
-
-For example, the following inserts three new documents, two with the
-supplied document IDs, and one which will have a document ID generated:
-
-.. code-block:: javascript
-
-    {
-       "docs" : [
-          {
-             "_id" : "FishStew",
-             "servings" : 4,
-             "subtitle" : "Delicious with fresh bread",
-             "title" : "Fish Stew"
-          },
-          {
-             "_id" : "LambStew",
-             "servings" : 6,
-             "subtitle" : "Delicious with scone topping",
-             "title" : "Lamb Stew"
-          },
-          {
-             "servings" : 8,
-             "subtitle" : "Delicious with suet dumplings",
-             "title" : "Beef Stew"
-          },
-       ]
-    }
-          
-
-The return type from a bulk insertion will be 201, with the content of
-the returned structure indicating specific success or otherwise messages
-on a per-document basis.
-
-The return structure from the example above contains a list of the
-documents created, here with the combination and their revision IDs:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_bulk_docs
-    Content-Type: application/json
-
-    [
-       {
-          "id" : "FishStew",
-          "rev" : "1-9c65296036141e575d32ba9c034dd3ee",
-       },
-       {
-          "id" : "LambStew",
-          "rev" : "1-34c318924a8f327223eed702ddfdc66d",
-       },
-       {
-          "id" : "7f7638c86173eb440b8890839ff35433",
-          "rev" : "1-857c7cbeb6c8dd1dd34a0c73e8da3c44",
-       }
-    ]
-              
-
-The content and structure of the returned JSON will depend on the transaction
-semantics being used for the bulk update; see :ref:`bulk-semantics` for more
-information. Conflicts and validation errors when updating documents in
-bulk must be handled separately; see :ref:`bulk-validation`.
-
-Updating Documents in Bulk
---------------------------
-
-The bulk document update procedure is similar to the insertion
-procedure, except that you must specify the document ID and current
-revision for every document in the bulk update JSON string.
-
-For example, you could send the following request:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_bulk_docs
-    Content-Type: application/json
-
-    {
-       "docs" : [
-          {
-             "_id" : "FishStew",
-             "_rev" : "1-9c65296036141e575d32ba9c034dd3ee",
-             "servings" : 4,
-             "subtitle" : "Delicious with freshly baked bread",
-             "title" : "Fish Stew"
-          },
-          {
-             "_id" : "LambStew",
-             "_rev" : "1-34c318924a8f327223eed702ddfdc66d",
-             "servings" : 6,
-             "subtitle" : "Serve with a wholemeal scone topping",
-             "title" : "Lamb Stew"
-          },
-          {
-             "_id" : "7f7638c86173eb440b8890839ff35433"
-             "_rev" : "1-857c7cbeb6c8dd1dd34a0c73e8da3c44",
-             "servings" : 8,
-             "subtitle" : "Hand-made dumplings make a great accompaniment",
-             "title" : "Beef Stew"
-          }
-       ]
-    }
-
-The return structure is the JSON of the updated documents, with the new
-revision and ID information:
-
-.. code-block:: javascript
-
-    [
-       {
-          "id" : "FishStew",
-          "rev" : "2-e7af4c4e9981d960ecf78605d79b06d1"
-       },
-       {
-          "id" : "LambStew",
-          "rev" : "2-0786321986194c92dd3b57dfbfc741ce"
-       },
-       {
-          "id" : "7f7638c86173eb440b8890839ff35433",
-          "rev" : "2-bdd3bf3563bee516b96885a66c743f8e"
-       }
-    ]
-
-You can optionally delete documents during a bulk update by adding the
-``_deleted`` field with a value of ``true`` to each document ID/revision
-combination within the submitted JSON structure.
-
-The return type from a bulk insertion will be 201, with the content of
-the returned structure indicating specific success or otherwise messages
-on a per-document basis.
-
-The content and structure of the returned JSON will depend on the transaction
-semantics being used for the bulk update; see :ref:`bulk-semantics` for more
-information. Conflicts and validation errors when updating documents in
-bulk must be handled separately; see :ref:`bulk-validation`.
-
-.. _bulk-semantics:
-
-Bulk Documents Transaction Semantics
-------------------------------------
-
-CouchDB supports two different modes for updating (or inserting)
-documents using the bulk documentation system. Each mode affects both
-the state of the documents in the event of system failure, and the level
-of conflict checking performed on each document. The two modes are:
-
--  ``non-atomic``
-
-   The default mode is non-atomic, that is, CouchDB will only guarantee
-   that some of the documents will be saved when you send the request.
-   The response will contain the list of documents successfully inserted
-   or updated during the process. In the event of a crash, some of the
-   documents may have been successfully saved, and some will have been
-   lost.
-
-   In this mode, the response structure will indicate whether the
-   document was updated by supplying the new ``_rev`` parameter
-   indicating a new document revision was created. If the update failed,
-   then you will get an ``error`` of type ``conflict``. For example:
-
-   .. code-block:: javascript
-
-       [
-          {
-             "id" : "FishStew",
-             "error" : "conflict",
-             "reason" : "Document update conflict."
-          },
-          {
-             "id" : "LambStew",
-             "error" : "conflict",
-             "reason" : "Document update conflict."
-          },
-          {
-             "id" : "7f7638c86173eb440b8890839ff35433",
-             "error" : "conflict",
-             "reason" : "Document update conflict."
-          }
-       ]
-           
-
-   In this case no new revision has been created and you will need to
-   submit the document update, with the correct revision tag, to update
-   the document.
-
--  ``all-or-nothing``
-
-   In all-or-nothing mode, either all documents are written to the
-   database, or no documents are written to the database, in the event
-   of a system failure during commit.
-
-   In addition, the per-document conflict checking is not performed.
-   Instead a new revision of the document is created, even if the new
-   revision is in conflict with the current revision in the database.
-   The returned structure contains the list of documents with new
-   revisions:
-
-   .. code-block:: javascript
-
-       [
-          {
-             "id" : "FishStew",
-             "rev" : "2-e7af4c4e9981d960ecf78605d79b06d1"
-          },
-          {
-             "id" : "LambStew",
-             "rev" : "2-0786321986194c92dd3b57dfbfc741ce"
-          },
-          {
-             "id" : "7f7638c86173eb440b8890839ff35433",
-             "rev" : "2-bdd3bf3563bee516b96885a66c743f8e"
-          }
-       ]
-
-   When updating documents using this mode the revision of a document
-   included in views will be arbitrary. You can check the conflict
-   status for a document by using the ``conflicts=true`` query argument
-   when accessing the view. Conflicts should be handled individually to
-   ensure the consistency of your database.
-
-   To use this mode, you must include the ``all_or_nothing`` field (set
-   to true) within the main body of the JSON of the request.
-
-The effects of different database operations on the different modes are
-summarized below:
-
-* **Transaction Mode**: ``Non-atomic``
-
-  * **Transaction**: ``Insert``
-
-    * **Cause**: Requested document ID already exists
-    * **Resolution**: Resubmit with different document ID, or update the
-      existing document
-
-  * **Transaction**: ``Update``
-
-    * **Cause**: Revision missing or incorrect
-    * **Resolution**: Resubmit with correct revision
-
-* **Transaction Mode**: ``All-or-nothing``
-
-  * **Transaction**: ``Insert`` / ``Update``
-
-    * **Cause**: Additional revision inserted
-    * **Resolution**: Resolve conflicted revisions
-
-Replication of documents is independent of the type of insert or update.
-The documents and revisions created during a bulk insert or update are
-replicated in the same way as any other document. This can mean that if
-you make use of the all-or-nothing mode the exact list of documents,
-revisions (and their conflict state) may or may not be replicated to
-other databases correctly.
-
-.. _bulk-validation:
-
-Bulk Document Validation and Conflict Errors
---------------------------------------------
-
-The JSON returned by the ``_bulk_docs`` operation consists of an array
-of JSON structures, one for each document in the original submission.
-The returned JSON structure should be examined to ensure that all of the
-documents submitted in the original request were successfully added to
-the database.
-
-The exact structure of the returned information is:
-
-+----------------------------------+-------------------------------------------+
-| Field                            | Description                               |
-+==================================+===========================================+
-| docs [array]                     | Bulk Documents Document                   |
-+----------------------------------+-------------------------------------------+
-|         id                       | Document ID                               |
-+----------------------------------+-------------------------------------------+
-|         error                    | Error type                                |
-+----------------------------------+-------------------------------------------+
-|         reason                   | Error string with extended reason         |
-+----------------------------------+-------------------------------------------+
-
-When a document (or document revision) is not correctly committed to the
-database because of an error, you should check the ``error`` field to
-determine error type and course of action. Errors will be one of the
-following type:
-
--  ``conflict``
-
-   The document as submitted is in conflict. If you used the default
-   bulk transaction mode then the new revision will not have been
-   created and you will need to re-submit the document to the database.
-   If you used ``all-or-nothing`` mode then you will need to manually
-   resolve the conflicted revisions of the document.
-
-   Conflict resolution of documents added using the bulk docs interface
-   is identical to the resolution procedures used when resolving
-   conflict errors during replication.
-
--  ``forbidden``
-
-   Entries with this error type indicate that the validation routine
-   applied to the document during submission has returned an error.
-
-   For example, if your validation routine includes the following:
-
-   .. code-block:: javascript
-
-        throw({forbidden: 'invalid recipe ingredient'});
-
-   The error returned will be:
-
-   .. code-block:: javascript
-
-       {
-          "id" : "7f7638c86173eb440b8890839ff35433",
-          "error" : "forbidden",
-          "reason" : "invalid recipe ingredient"
-       }
-             
-
-``POST /db/_temp_view``
-=======================
-
-* **Method**: ``POST /db/_temp_view``
-* **Request**: JSON with the temporary view definition
-* **Response**: Temporary view result set
-* **Admin Privileges Required**: yes
-
-Creates (and executes) a temporary view based on the view function
-supplied in the JSON request. For example:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_temp_view
-    Content-Type: application/json
-
-    {
-       "map" : "function(doc) { if (doc.value > 9995) { emit(null, doc.value); } }"
-    }
-
-The resulting JSON response is the result from the execution of the
-temporary view:
-
-.. code-block:: javascript
-
-    {
-       "total_rows" : 3,
-       "rows" : [
-          {
-             "value" : 9998.41913029012,
-             "id" : "05361cc6aa42033878acc1bacb1f39c2",
-             "key" : null
-          },
-          {
-             "value" : 9998.94149934853,
-             "id" : "1f443f471e5929dd7b252417625ed170",
-             "key" : null
-          },
-          {
-             "value" : 9998.01511339154,
-             "id" : "1f443f471e5929dd7b252417629c102b",
-             "key" : null
-          }
-       ],
-       "offset" : 0
-    }
-
-The arguments also available to standard view requests also apply to
-temporary views, but the execution of the view may take some time as it
-relies on being executed at the time of the request. In addition to the
-time taken, they are also computationally very expensive to produce. You
-should use a defined view if you want to achieve the best performance.
-
-``POST /db/_purge``
-===================
-
-* **Method**: ``POST /db/_purge``
-* **Request**: JSON of the document IDs/revisions to be purged
-* **Response**: JSON structure with purged documents and purge sequence
-* **Admin Privileges Required**: no
-
-A database purge permanently removes the references to deleted documents
-from the database. Deleting a document within CouchDB does not actually
-remove the document from the database, instead, the document is marked as
-a deleted (and a new revision is created). This is to ensure that
-deleted documents are replicated to other databases as having been
-deleted. This also means that you can check the status of a document and
-identify that the document has been deleted.
-
-The purge operation removes the references to the deleted documents from
-the database. The purging of old documents is not replicated to other
-databases. If you are replicating between databases and have deleted a
-large number of documents you should run purge on each database.
-
-.. note::
-
-   Purging documents does not remove the space used by them on disk. To
-   reclaim disk space, you should run a database compact (see
-   :ref:`api-compact`), and compact views (see :ref:`api-compact-ddoc`).
-
-To perform a purge operation you must send a request including the JSON
-of the document IDs that you want to purge. For example:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_purge
-    Content-Type: application/json
-
-    {
-      "FishStew" : [
-        "17-b3eb5ac6fbaef4428d712e66483dcb79"
-        ]
-    }
-
-The format of the request must include the document ID and one or more
-revisions that must be purged.
-
-The response will contain the purge sequence number, and a list of the
-document IDs and revisions successfully purged.
-
-.. code-block:: javascript
-
-    {
-       "purged" : {
-          "FishStew" : [
-             "17-b3eb5ac6fbaef4428d712e66483dcb79"
-          ]
-       },
-       "purge_seq" : 11
-    }
-
-Updating Indexes
-----------------
-
-The number of purges on a database is tracked using a purge sequence.
-This is used by the view indexer to optimize the updating of views that
-contain the purged documents.
-
-When the indexer identifies that the purge sequence on a database has
-changed, it compares the purge sequence of the database with that stored
-in the view index. If the difference between the stored sequence and
-database is sequence is only 1, then the indexer uses a cached list of
-the most recently purged documents, and then removes these documents
-from the index individually. This prevents completely rebuilding the
-index from scratch.
-
-If the difference between the stored sequence number and current
-database sequence is greater than 1, then the view index is entirely
-rebuilt. This is an expensive operation as every document in the
-database must be examined.
-
-``GET /db/_all_docs``
-=====================
-
-* **Method**: ``GET /db/_all_docs``
-* **Request**: None
-* **Response**: JSON object containing document information, ordered by the
-  document ID
-* **Admin Privileges Required**: no
-* **Query Arguments**:
-
-  * **Argument**: descending
-
-    * **Description**:  Return the documents in descending by key order
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: false
-
-  * **Argument**: endkey
-
-    * **Description**:  Stop returning records when the specified key is reached
-    * **Optional**: yes
-    * **Type**: string
-
-  * **Argument**: endkey_docid
-
-    * **Description**:  Stop returning records when the specified document ID is
-      reached
-    * **Optional**: yes
-    * **Type**: string
-
-  * **Argument**: group
-
-    * **Description**:  Group the results using the reduce function to a group
-      or single row
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: false
-
-  * **Argument**: group_level
-
-    * **Description**:  Specify the group level to be used
-    * **Optional**: yes
-    * **Type**: numeric
-
-  * **Argument**: include_docs
-
-    * **Description**:  Include the full content of the documents in the return
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: false
-
-  * **Argument**: inclusive_end
-
-    * **Description**:  Specifies whether the specified end key should be
-      included in the result
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: true
-
-  * **Argument**: key
-
-    * **Description**:  Return only documents that match the specified key
-    * **Optional**: yes
-    * **Type**: string
-
-  * **Argument**: limit
-
-    * **Description**:  Limit the number of the returned documents to the
-      specified number
-    * **Optional**: yes
-    * **Type**: numeric
-
-  * **Argument**: reduce
-
-    * **Description**:  Use the reduction function
-    * **Optional**: yes
-    * **Type**: boolean
-    * **Default**: true
-
-  * **Argument**: skip
-
-    * **Description**:  Skip this number of records before starting to return
-      the results
-    * **Optional**: yes
-    * **Type**: numeric
-    * **Default**: 0
-
-  * **Argument**: stale
-
-    * **Description**:  Allow the results from a stale view to be used
-    * **Optional**: yes
-    * **Type**: string
-    * **Default**:
-    * **Supported Values**:
-
-      * **ok**: Allow stale views
-
-  * **Argument**: startkey
-
-    * **Description**:  Return records starting with the specified key
-    * **Optional**: yes
-    * **Type**: string
-
-  * **Argument**: startkey_docid
-
-    * **Description**:  Return records starting with the specified document ID
-    * **Optional**: yes
-    * **Type**: string
-
-Returns a JSON structure of all of the documents in a given database.
-The information is returned as a JSON structure containing meta
-information about the return structure, and the list documents and basic
-contents, consisting the ID, revision and key. The key is generated from
-the document ID.
-
-+----------------------------------+-------------------------------------------+
-| Field                            | Description                               |
-+==================================+===========================================+
-| offset                           | Offset where the document list started    |
-+----------------------------------+-------------------------------------------+
-| rows [array]                     | Array of document object                  |
-+----------------------------------+-------------------------------------------+
-| total_rows                       | Number of documents in the database/view  |
-+----------------------------------+-------------------------------------------+
-| update_seq                       | Current update sequence for the database  |
-+----------------------------------+-------------------------------------------+
-
-By default the information returned contains only the document ID and
-revision. For example, the request:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/recipes/_all_docs
-    Accept: application/json
-
-Returns the following structure:
-
-.. code-block:: javascript
-
-    {
-       "total_rows" : 18386,
-       "rows" : [
-          {
-             "value" : {
-                "rev" : "1-bc0d5aed1e339b1cc1f29578f3220a45"
-             },
-             "id" : "Aberffrawcake",
-             "key" : "Aberffrawcake"
-          },
-          {
-             "value" : {
-                "rev" : "3-68a20c89a5e70357c20148f8e82ca331"
-             },
-             "id" : "Adukiandorangecasserole-microwave",
-             "key" : "Adukiandorangecasserole-microwave"
-          },
-          {
-             "value" : {
-                "rev" : "3-9b2851ed9b6f655cc4eb087808406c60"
-             },
-             "id" : "Aioli-garlicmayonnaise",
-             "key" : "Aioli-garlicmayonnaise"
-          },
-          ...
-             ],
-       "offset" : 0
-    }
-
-The information is returned in the form of a temporary view of all the
-database documents, with the returned key consisting of the ID of the
-document. The remainder of the interface is therefore identical to the
-View query arguments and their behavior.
-
-``POST /db/_all_docs``
-======================
-
-* **Method**: ``POST /db/_all_docs``
-* **Request**: JSON of the document IDs you want included
-* **Response**: JSON of the returned view
-* **Admin Privileges Required**: no
-
-The ``POST`` to ``_all_docs`` allows to specify multiple keys to be
-selected from the database. This enables you to request multiple
-documents in a single request, in place of multiple
-:ref:`api-get-doc` requests.
-
-The request body should contain a list of the keys to be returned as an
-array to a ``keys`` object. For example:
-
-.. code-block:: http
-
-    POST http://couchdb:5984/recipes/_all_docs
-    User-Agent: MyApp/0.1 libwww-perl/5.837
-
-    {
-       "keys" : [
-          "Zingylemontart",
-          "Yogurtraita"
-       ]
-    }
-
-The return JSON is the all documents structure, but with only the
-selected keys in the output:
-
-.. code-block:: javascript
-
-    {
-       "total_rows" : 2666,
-       "rows" : [
-          {
-             "value" : {
-                "rev" : "1-a3544d296de19e6f5b932ea77d886942"
-             },
-             "id" : "Zingylemontart",
-             "key" : "Zingylemontart"
-          },
-          {
-             "value" : {
-                "rev" : "1-91635098bfe7d40197a1b98d7ee085fc"
-             },
-             "id" : "Yogurtraita",
-             "key" : "Yogurtraita"
-          }
-       ],
-       "offset" : 0
-    }
-
-``POST /db/_missing_revs``
-==========================
-
-* **Method**: ``POST /db/_missing_revs``
-* **Request**: JSON list of document revisions
-* **Response**: JSON of missing revisions
-* **Admin Privileges Required**: no
-
-``POST /db/_revs_diff``
-=======================
-
-* **Method**: ``POST /db/_revs_diff``
-* **Request**: JSON list of document revisions
-* **Response**: JSON list of differences from supplied document/revision list
-* **Admin Privileges Required**: no
-
-``GET /db/_security``
-=====================
-
-* **Method**: ``GET /db/_security``
-* **Request**: None
-* **Response**: JSON of the security object
-* **Admin Privileges Required**: no
-
-Gets the current security object from the specified database. The
-security object consists of two compulsory elements, ``admins`` and
-``readers``, which are used to specify the list of users and/or roles
-that have admin and reader rights to the database respectively. Any
-additional fields in the security object are optional. The entire
-security object is made available to validation and other internal
-functions so that the database can control and limit functionality.
-
-To get the existing security object you would send the following
-request:
-
-.. code-block:: javascript
-
-    {
-       "admins" : {
-          "roles" : [],
-          "names" : [
-             "mc",
-             "slp"
-          ]
-       },
-       "readers" : {
-          "roles" : [],
-          "names" : [
-             "tim",
-             "brian"
-          ]
-       }
-    }
-
-Security object structure is:
-
-* **admins**: Roles/Users with admin privileges
-
-  * **roles** [array]: List of roles with parent privilege
-  * **users** [array]: List of users with parent privilege
-
-* **readers**: Roles/Users with reader privileges
-
-  * **roles** [array]: List of roles with parent privilege
-  * **users** [array]: List of users with parent privilege
-
-.. note::
-   If the security object for a database has never been set, then the
-   value returned will be empty.
-
-``PUT /db/_security``
-=====================
-
-* **Method**: ``PUT /db/_security``
-* **Request**: JSON specifying the admin and user security for the database
-* **Response**: JSON status message
-* **Admin Privileges Required**: no
-
-Sets the security object for the given database.For example, to set the
-security object for the ``recipes`` database:
-
-.. code-block:: javascript
-
-    PUT http://couchdb:5984/recipes/_security
-    Content-Type: application/json
-
-    {
-       "admins" : {
-          "roles" : [],
-          "names" : [
-             "mc",
-             "slp"
-          ]
-       },
-       "readers" : {
-          "roles" : [],
-          "names" : [
-             "tim",
-             "brian"
-          ]
-       }
-    }
-
-If the setting was successful, a JSON status object will be returned:
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-
-``GET /db/_revs_limit``
-=======================
-
-* **Method**: ``GET /db/_revs_limit``
-* **Request**: None
-* **Response**: The current revision limit setting
-* **Admin Privileges Required**: no
-
-
-Gets the current ``revs_limit`` (revision limit) setting.
-
-For example to get the current limit:
-
-.. code-block:: http
-
-    GET http://couchdb:5984/recipes/_revs_limit
-    Content-Type: application/json
-
-The returned information is the current setting as a numerical scalar:
-
-.. code-block:: javascript
-
-    1000
-
-``PUT /db/_revs_limit``
-=======================
-
-* **Method**: ``PUT /db/_revs_limit``
-* **Request**: A scalar integer of the revision limit setting
-* **Response**: Confirmation of setting of the revision limit
-* **Admin Privileges Required**: no
-
-Sets the maximum number of document revisions that will be tracked by
-CouchDB, even after compaction has occurred. You can set the revision
-limit on a database by using ``PUT`` with a scalar integer of the limit
-that you want to set as the request body.
-
-For example to set the revs limit to 100 for the ``recipes`` database:
-
-.. code-block:: http
-
-    PUT http://couchdb:5984/recipes/_revs_limit
-    Content-Type: application/json
-
-    100
-
-If the setting was successful, a JSON status object will be returned:
-
-.. code-block:: javascript
-
-    {
-       "ok" : true
-    }
-
-.. _JSON object: #table-couchdb-api-db_db-json-changes

http://git-wip-us.apache.org/repos/asf/couchdb/blob/0357f044/share/docs/rst/api/dbmaint.rst
----------------------------------------------------------------------
diff --git a/share/docs/rst/api/dbmaint.rst b/share/docs/rst/api/dbmaint.rst
deleted file mode 100644
index 8686caf..0000000
--- a/share/docs/rst/api/dbmaint.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-====================
-Database Maintenance
-====================


Mime
View raw message