You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by dc...@apache.org on 2012/09/14 12:16:59 UTC
[13/49] git commit: Clean up imported .rst
Clean up imported .rst
- Fix markup of errors section
- Fix caution blocks
- Add back JSON structure reference
- Clarify what kind of contents should go in views
- Add back configuration option reference
- Add TODO.txt for future reference
- Add tables to start of API reference sections (except for design docs)
- Fix indentation
- Add syntax highlighting
- Add to-do statements
- Fix weird `_` escaping
- Wrap statements
- Add method descriptions
- Clean up tables
- Add missed `PUT /db/_revs_limit` description
Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/010be920
Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/010be920
Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/010be920
Branch: refs/heads/docs
Commit: 010be92031edda7a6c0ce2aa5f0533f1865577bc
Parents: 3968d98
Author: Alexander Shorin <kx...@gmail.com>
Authored: Wed Aug 1 18:02:03 2012 +0200
Committer: Dave Cottlehuber <dc...@apache.org>
Committed: Thu Aug 23 23:06:51 2012 +0200
----------------------------------------------------------------------
.gitignore | 2 +-
share/docs/sphinx-docs/1.1/commonjs.rst | 50 -
share/docs/sphinx-docs/1.1/index.rst | 36 -
share/docs/sphinx-docs/1.1/other.rst | 148 --
share/docs/sphinx-docs/1.1/proxy.rst | 84 -
share/docs/sphinx-docs/1.1/range.rst | 59 -
share/docs/sphinx-docs/1.1/replicator.rst | 367 ----
share/docs/sphinx-docs/1.1/ssl.rst | 97 -
share/docs/sphinx-docs/Makefile | 153 --
share/docs/sphinx-docs/api.rst | 434 -----
share/docs/sphinx-docs/api/authn.rst | 10 -
share/docs/sphinx-docs/api/configuration.rst | 216 ---
share/docs/sphinx-docs/api/database.rst | 972 -----------
share/docs/sphinx-docs/api/dbmaint.rst | 3 -
share/docs/sphinx-docs/api/design.rst | 784 ---------
share/docs/sphinx-docs/api/documents.rst | 600 -------
share/docs/sphinx-docs/api/local.rst | 53 -
share/docs/sphinx-docs/api/misc.rst | 606 -------
share/docs/sphinx-docs/api/reference.rst | 16 -
share/docs/sphinx-docs/changes.rst | 26 -
share/docs/sphinx-docs/conf.py | 242 ---
share/docs/sphinx-docs/config.rst | 105 --
share/docs/sphinx-docs/configuring.rst | 210 ---
share/docs/sphinx-docs/errors.rst | 26 -
share/docs/sphinx-docs/features.rst | 193 --
share/docs/sphinx-docs/images/futon-createdb.png | Bin 76194 -> 0 bytes
share/docs/sphinx-docs/images/futon-editdoc.png | Bin 64369 -> 0 bytes
share/docs/sphinx-docs/images/futon-editeddoc.png | Bin 69595 -> 0 bytes
share/docs/sphinx-docs/images/futon-overview.png | Bin 63039 -> 0 bytes
share/docs/sphinx-docs/images/futon-replform.png | Bin 68068 -> 0 bytes
share/docs/sphinx-docs/index.rst | 32 -
share/docs/sphinx-docs/intro.rst | 285 ---
share/docs/sphinx-docs/make.bat | 190 --
share/docs/sphinx-docs/replication.rst | 371 ----
share/docs/sphinx-docs/views.rst | 2 -
share/sphinx-docs/1.1/commonjs.rst | 52 +
share/sphinx-docs/1.1/index.rst | 35 +
share/sphinx-docs/1.1/other.rst | 148 ++
share/sphinx-docs/1.1/proxy.rst | 80 +
share/sphinx-docs/1.1/range.rst | 60 +
share/sphinx-docs/1.1/replicator.rst | 369 ++++
share/sphinx-docs/1.1/ssl.rst | 97 +
share/sphinx-docs/Makefile | 153 ++
share/sphinx-docs/TODO.txt | 11 +
share/sphinx-docs/api-basics.rst | 435 +++++
share/sphinx-docs/api/authn.rst | 29 +
share/sphinx-docs/api/configuration.rst | 285 +++
share/sphinx-docs/api/database.rst | 1451 ++++++++++++++++
share/sphinx-docs/api/dbmaint.rst | 3 +
share/sphinx-docs/api/design.rst | 1250 +++++++++++++
share/sphinx-docs/api/documents.rst | 919 ++++++++++
share/sphinx-docs/api/local.rst | 157 ++
share/sphinx-docs/api/misc.rst | 793 +++++++++
share/sphinx-docs/api/reference.rst | 16 +
share/sphinx-docs/changes.rst | 28 +
share/sphinx-docs/conf.py | 242 +++
share/sphinx-docs/configuring.rst | 490 ++++++
share/sphinx-docs/features.rst | 191 ++
share/sphinx-docs/images/futon-createdb.png | Bin 0 -> 76194 bytes
share/sphinx-docs/images/futon-editdoc.png | Bin 0 -> 64369 bytes
share/sphinx-docs/images/futon-editeddoc.png | Bin 0 -> 69595 bytes
share/sphinx-docs/images/futon-overview.png | Bin 0 -> 63039 bytes
share/sphinx-docs/images/futon-replform.png | Bin 0 -> 68068 bytes
share/sphinx-docs/index.rst | 31 +
share/sphinx-docs/intro.rst | 300 ++++
share/sphinx-docs/json-structure.rst | 401 +++++
share/sphinx-docs/make.bat | 190 ++
share/sphinx-docs/replication.rst | 375 ++++
share/sphinx-docs/views.rst | 6 +
69 files changed, 8598 insertions(+), 6371 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/.gitignore
----------------------------------------------------------------------
diff --git a/.gitignore b/.gitignore
index eca45a6..0206e1e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -91,7 +91,7 @@ test/etap/test_util.erl
test/javascript/run
share/server/main.js
share/server/main-coffee.js
-share/docs/sphinx-docs/build
+share/sphinx-docs/build
# for make dev
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/commonjs.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/commonjs.rst b/share/docs/sphinx-docs/1.1/commonjs.rst
deleted file mode 100644
index 29961e5..0000000
--- a/share/docs/sphinx-docs/1.1/commonjs.rst
+++ /dev/null
@@ -1,50 +0,0 @@
-Added CommonJS support to map functions
-=======================================
-
-We didn't have CommonJS require in map functions because the current
-CommonJS implementation is scoped to the whole design doc, and giving
-views access to load code from anywhere in the design doc would mean
-we'd have to blow away your view index any time you changed anything.
-Having to rebuild views from scratch just because you changed some CSS
-or a show function isn't fun, so we avoided the issue by keeping
-CommonJS require out of map and reduce altogether.
-
-The solution we came up with is to allow CommonJS inside map and reduce
-funs, but only of libraries that are stored inside the views part of the
-design doc.
-
-So you could continue to access CommonJS code in design\_doc.foo, from
-your list functions etc, but we'd add the ability to require CommonJS
-modules within map and reduce, but only from design\_doc.views.lib
-
-There's no worry here about namespace collisions, as Couch just plucks
-``views.*.map`` and ``views.*.reduce`` out of the design doc. So you
-could have a view called ``lib`` if you wanted, and still have CommonJS
-stored in ``views.lib.sha1`` and ``views.lib.stemmer`` if you wanted.
-
-We simplified the implementation by enforcing that CommonJS modules to
-be used in map functions be stored in views.lib.
-
-A sample design doc (taken from the test suite in Futon) is below:
-
-::
-
- {
- "views" : {
- "lib" : {
- "baz" : "exports.baz = 'bam';",
- "foo" : {
- "zoom" : "exports.zoom = 'yeah';",
- "boom" : "exports.boom = 'ok';",
- "foo" : "exports.foo = 'bar';"
- }
- },
- "commonjs" : {
- "map" : "function(doc) { emit(null, require('views/lib/foo/boom').boom)}"
- }
- },
- "_id" : "_design/test"
- }
-
-The ``require()`` statement is relative to the design document, but
-anything loaded form outside of ``views/lib`` will fail.
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/index.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/index.rst b/share/docs/sphinx-docs/1.1/index.rst
deleted file mode 100644
index 106caf4..0000000
--- a/share/docs/sphinx-docs/1.1/index.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-=================================
-CouchDB Release 1.1 Feature Guide
-=================================
-
-Upgrading to CouchDB 1.1
-========================
-
-You can upgrade your existing CouchDB 1.0.x installation to CouchDB 1.1
-without any specific steps or migration. When you run CouchDB 1.1 the
-existing data and index files will be opened and used as normal.
-
-The first time you run a compaction routine on your database within
-CouchDB 1.1, the data structure and indexes will be updated to the new
-version of the CouchDB database format that can only be read by CouchDB
-1.1 and later. This step is not reversable. Once the data files have
-been updated and migrated to the new version the data files will no
-longer work with a CouchDB 1.0.x release.
-
- **Warning**
-
- If you want to retain support for openein gthe data files in CouchDB
- 1.0.x you must back up your data files before performing the upgrade
- and compaction process.
-
-New features in CouchDB 1.1
-===========================
-
-.. toctree::
- :maxdepth: 2
-
- replicator
- ssl
- range
- proxy
- commonjs
- other
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/other.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/other.rst b/share/docs/sphinx-docs/1.1/other.rst
deleted file mode 100644
index 3de1774..0000000
--- a/share/docs/sphinx-docs/1.1/other.rst
+++ /dev/null
@@ -1,148 +0,0 @@
-More granular ETag support for views
-====================================
-
-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.
-
-In CouchDB 1.1 each ``_view`` URL has it's 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).
-
-Added built-in filters for ``_changes``: ``_doc_ids`` and ``_design``.
-======================================================================
-
-The ``_changes`` feed can now 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" as a JSON array.
-
-Allow wildcards in vhosts definitions
-=====================================
-
-Similar to the rewrites section of a ``_design`` document, the new
-``vhosts`` system uses variables in the form of :varname or wildcards in
-the form of asterisks. The variable results can be output into the
-resulting path as they are in the rewriter.
-
-OS Daemons
-==========
-
-CouchDB now supports starting external processes. The support is simple
-and enables CouchDB to start each configured OS daemon. If the daemon
-stops at any point, CouchDB will restart it (with protection to ensure
-regularly failing daemons are not repeatedly restarted).
-
-The daemon starting process is one-to-one; for each each configured
-daemon in the configuration file, CouchDB will start exactly one
-instance. If you need to run multiple instances, then you must create
-separate individual configurations. Daemons are configured within the
-``[os_daemons]`` section of your configuration file (``local.ini``). The
-format of each configured daemon is:
-
-::
-
- NAME = PATH ARGS
-
-
-Where ``NAME`` is an arbitrary (and unique) name to identify the daemon;
-``PATH`` is the full path to the daemon to be executed; ``ARGS`` are any
-required arguments to the daemon.
-
-For example:
-
-::
-
- [os_daemons]
- basic_responder = /usr/local/bin/responsder.js
-
-There is no interactivity between CouchDB and the running process, but
-you can use the OS Daemons service to create new HTTP servers and
-responders and then use the new proxy service to redirect requests and
-output to the CouchDB managed service. For more information on proxying,
-see ?. For further background on the OS Daemon service, see `CouchDB
-Externals API`_
-
-Stale views and ``update_after``
-================================
-
-Currently a view request can include the ``stale=ok`` query argument,
-which allows the contents of a stale view index to be used to produce
-the view output. In order to trigger a build of the outdated view index,
-a second view request must be made.
-
-To simplify this process, the ``update_after`` value can be supplied to
-the ``stale`` query argument. This triggers a rebuild of the view index
-after the results of the view have been retrieved.
-
-Socket Options Configuration Setting
-====================================
-
-The socket options for the listening socket in CouchDB can now be set
-within the CouchDB configuration file. The setting should be added to
-the ``[httpd]`` section of the file using the option name
-``socket_options``. The specification is as a list of tuples. For
-example:
-
-::
-
- [httpd]
- socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]
-
-The options supported are a subset of full options supported by the
-TCP/IP stack. A list of the supported options are provided in the
-`Erlang inet`_ documentation.
-
-Server Options Configuration Setting
-====================================
-
-Server options for the MochiWeb component of CouchDB can now be added to
-the configuration file. Settings should be added to the
-``server_options`` option of the ``[httpd]`` section of ``local.ini``.
-For example:
-
-::
-
- [httpd]
- server_options = [{backlog, 128}, {acceptor_pool_size, 16}]
-
-
-Improved Error Messages
-=======================
-
-The errors reported when CouchDB is unable to read a required file have
-been updated so that explicit information about the files and problem
-can now be identified from the error message. The errors report file
-permission access either when reading or writing to configuration and
-database files.
-
-The error is raised both through the log file and the error message
-returned through the API call as a JSON error message. For example, when
-setting configuration values:
-
-::
-
- shell>
- {"error":"file_permission_error","reason":"/etc/couchdb/local.ini"}
-
-
-Errors will always be reported using the ``file_permission_error`` error
-type.
-
-During startup permissions errors on key files are also reported in the
-log with a descriptive error message and file location so that
-permissions can be fixed before restart.
-
-Multiple micro-optimizations when reading data.
-===============================================
-
-We found a number of places where CouchDB wouldn't do the absolute
-optimal thing when reading data and got rid of quite a few
-inefficiencies. The problem with small optimizations all over the place
-is that you may not notice them with every use-case, but we sure hope
-you can see an improvement overall.
-
-.. _CouchDB Externals API: http://davispj.com/2010/09/26/new-couchdb-externals-api.html
-.. _Erlang inet: http://www.erlang.org/doc/man/inet.html#setopts-2
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/proxy.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/proxy.rst b/share/docs/sphinx-docs/1.1/proxy.rst
deleted file mode 100644
index 12d6e7d..0000000
--- a/share/docs/sphinx-docs/1.1/proxy.rst
+++ /dev/null
@@ -1,84 +0,0 @@
-HTTP Proxying
-=============
-
-The HTTP proxy feature makes it easy to map and redirect different
-content through your CouchDB URL. The proxy works by mapping a pathname
-and passing all content after that prefix through to the configured
-proxy address.
-
-Configuration of the proxy redirect is handled through the
-``[httpd_global_handlers]`` section of the CouchDB configuration file
-(typically ``local.ini``). The format is:
-
-::
-
- [httpd_global_handlers]
- PREFIX = {couch_httpd_proxy, handle_proxy_req, <<"DESTINATION">>}
-
-
-Where:
-
-- ``PREFIX``
-
- Is the string that will be matched. The string can be any valid
- qualifier, although to ensure that existing database names are not
- overridden by a proxy configuration, you can use an underscore
- prefix.
-
-- ``DESTINATION``
-
- The fully-qualified URL to which the request should be sent. The
- destination must include the ``http`` prefix. The content is used
- verbatim in the original request, so you can also forward to servers
- on different ports and to specific paths on the target host.
-
-The proxy process then translates requests of the form:
-
-::
-
- http://couchdb:5984/PREFIX/path
-
-To:
-
-::
-
- DESTINATION/path
-
- **Note**
-
- Everything after ``PREFIX`` including the required forward slash
- will be appended to the ``DESTINATION``.
-
-The response is then communicated back to the original client.
-
-For example, the following configuration:
-
-::
-
-
- _google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>}
-
-Would forward all requests for ``http://couchdb:5984/_google`` to the
-Google website.
-
-The service can also be used to forward to related CouchDB services,
-such as Lucene:
-
-::
-
-
- [httpd_global_handlers]
- _fti = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985">>}
-
- **Note**
-
- The proxy service is basic. If the request is not identified by the
- ``DESTINATION``, or the remainder of the ``PATH`` specification is
- incomplete, the original request URL is interpreted as if the
- ``PREFIX`` component of that URL does not exist.
-
- For example, requesting ``http://couchdb:5984/_intranet/media`` when
- ``/media`` on the proxy destination does not exist, will cause the
- request URL to be interpreted as ``http://couchdb:5984/media``. Care
- should be taken to ensure that both requested URLs and destination
- URLs are able to cope
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/range.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/range.rst b/share/docs/sphinx-docs/1.1/range.rst
deleted file mode 100644
index 5dbc9fd..0000000
--- a/share/docs/sphinx-docs/1.1/range.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-HTTP Range Requests
-===================
-
-HTTP allows you to specify byte ranges for requests. This allows the
-implementation of resumable downloads and skippable audio and video
-streams alike. Now this is available for all attachments inside CouchDB.
-
-This is just a real quick run through how this looks under the hood.
-Usually, you will have larger binary files to serve from CouchDB, like
-MP3s and videos, but to make things a little more obvious, I use a text
-file here (Note that I use the ``application/octet-stream`` Content-Type
-instead of ``text/plain``).
-
-::
-
- shell>
- My hovercraft is full of eels!
-
-Now lets store this text file as an attachment in CouchDB. First, we
-create a database:
-
-::
-
- shell>
- {"ok":true}
-
-Then we create a new document and the file attachment in one go:
-
-::
-
- shell>
- {"ok":true,"id":"doc","rev":"1-287a28fa680ae0c7fb4729bf0c6e0cf2"}
-
-Now we can request the whole file easily:
-
-::
-
- shell>
- My hovercraft is full of eels!
-
-But say we only want the first 13 bytes:
-
-::
-
- shell>
- My hovercraft
-
-HTTP supports many ways to specify single and even multiple byte
-rangers. Read all about it in `RFC 2616`_.
-
- **Note**
-
- Databases that have been created with CouchDB 1.0.2 or earlier will
- support range requests in 1.1.0, but they are using a less-optimal
- algorithm. If you plan to make heavy use of this feature, make sure
- to compact your database with CouchDB 1.1.0 to take advantage of a
- better algorithm to find byte ranges.
-
-.. _RFC 2616: http://tools.ietf.org/html/rfc2616#section-14.27
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/replicator.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/replicator.rst b/share/docs/sphinx-docs/1.1/replicator.rst
deleted file mode 100644
index f8a7d0a..0000000
--- a/share/docs/sphinx-docs/1.1/replicator.rst
+++ /dev/null
@@ -1,367 +0,0 @@
-Replicator Database
-===================
-
-A database where you ``PUT``/``POST`` documents to trigger replications
-and you ``DELETE`` to cancel ongoing replications. These documents have
-exactly the same content as the JSON objects we used to ``POST`` to
-``_replicate`` (fields ``source``, ``target``, ``create_target``,
-``continuous``, ``doc_ids``, ``filter``, ``query_params``.
-
-Replication documents can have a user defined ``_id``. Design documents
-(and ``_local`` documents) added to the replicator database are ignored.
-
-The default name of this database is ``_replicator``. The name can be
-changed in the ``local.ini`` configuration, section ``[replicator]``,
-parameter ``db``.
-
-Basics
-------
-
-Let's say you PUT the following document into \_replicator:
-
-::
-
- {
- "_id": "my_rep",
- "source": "http://myserver.com:5984/foo",
- "target": "bar",
- "create_target": true
- }
-
-In the couch log you'll see 2 entries like these:
-
-::
-
- [Thu, 17 Feb 2011 19:43:59 GMT] [info] [<0.291.0>] Document `my_rep` triggered replication `c0ebe9256695ff083347cbf95f93e280+create_target`
- [Thu, 17 Feb 2011 19:44:37 GMT] [info] [<0.124.0>] Replication `c0ebe9256695ff083347cbf95f93e280+create_target` finished (triggered by document `my_rep`)
-
-As soon as the replication is triggered, the document will be updated by
-CouchDB with 3 new fields:
-
-::
-
- {
- "_id": "my_rep",
- "source": "http://myserver.com:5984/foo",
- "target": "bar",
- "create_target": true,
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280",
- "_replication_state": "triggered",
- "_replication_state_time": 1297974122
- }
-
-Special fields set by the replicator start with the prefix
-``_replication_``.
-
-- ``_replication_id``
-
- The ID internally assigned to the replication. This is also the ID
- exposed by ``/_active_tasks``.
-
-- ``_replication_state``
-
- The current state of the replication.
-
-- ``_replication_state_time``
-
- A Unix timestamp (number of seconds since 1 Jan 1970) that tells us
- when the current replication state (marked in ``_replication_state``)
- was set.
-
-When the replication finishes, it will update the ``_replication_state``
-field (and ``_replication_state_time``) with the value ``completed``, so
-the document will look like:
-
-::
-
- {
- "_id": "my_rep",
- "source": "http://myserver.com:5984/foo",
- "target": "bar",
- "create_target": true,
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280",
- "_replication_state": "completed",
- "_replication_state_time": 1297974122
- }
-
-When an error happens during replication, the ``_replication_state``
-field is set to ``error`` (and ``_replication_state`` gets updated of
-course).
-
-When you PUT/POST a document to the ``_replicator`` database, CouchDB
-will attempt to start the replication up to 10 times (configurable under
-``[replicator]``, parameter ``max_replication_retry_count``). If it
-fails on the first attempt, it waits 5 seconds before doing a second
-attempt. If the second attempt fails, it waits 10 seconds before doing a
-third attempt. If the third attempt fails, it waits 20 seconds before
-doing a fourth attempt (each attempt doubles the previous wait period).
-When an attempt fails, the Couch log will show you something like:
-
-::
-
- [error] [<0.149.0>] Error starting replication `67c1bb92010e7abe35d7d629635f18b6+create_target` (document `my_rep_2`): {db_not_found,<<"could not open http://myserver:5986/foo/">>
-
- **Note**
-
- The ``_replication_state`` field is only set to ``error`` when all
- the attempts were unsuccessful.
-
-There are only 3 possible values for the ``_replication_state`` field:
-``triggered``, ``completed`` and ``error``. Continuous replications
-never get their state set to ``completed``.
-
-Documents describing the same replication
------------------------------------------
-
-Lets suppose 2 documents are added to the ``_replicator`` database in
-the following order:
-
-::
-
- {
- "_id": "doc_A",
- "source": "http://myserver.com:5984/foo",
- "target": "bar"
- }
-
-and
-
-::
-
- {
- "_id": "doc_B",
- "source": "http://myserver.com:5984/foo",
- "target": "bar"
- }
-
-Both describe exactly the same replication (only their ``_ids`` differ).
-In this case document ``doc_A`` triggers the replication, getting
-updated by CouchDB with the fields ``_replication_state``,
-``_replication_state_time`` and ``_replication_id``, just like it was
-described before. Document ``doc_B`` however, is only updated with one
-field, the ``_replication_id`` so it will look like this:
-
-::
-
- {
- "_id": "doc_B",
- "source": "http://myserver.com:5984/foo",
- "target": "bar",
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280"
- }
-
-While document ``doc_A`` will look like this:
-
-::
-
- {
- "_id": "doc_A",
- "source": "http://myserver.com:5984/foo",
- "target": "bar",
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280",
- "_replication_state": "triggered",
- "_replication_state_time": 1297974122
- }
-
-Note that both document get exactly the same value for the
-``_replication_id`` field. This way you can identify which documents
-refer to the same replication - you can for example define a view which
-maps replication IDs to document IDs.
-
-Canceling replications
-----------------------
-
-To cancel a replication simply ``DELETE`` the document which triggered
-the replication. The Couch log will show you an entry like the
-following:
-
-::
-
- [Thu, 17 Feb 2011 20:16:29 GMT] [info] [<0.125.0>] Stopped replication `c0ebe9256695ff083347cbf95f93e280+continuous+create_target` because replication document `doc_A` was deleted
-
- **Note**
-
- You need to ``DELETE`` the document that triggered the replication.
- ``DELETE``\ ing another document that describes the same replication
- but did not trigger it, will not cancel the replication.
-
-Server restart
---------------
-
-When CouchDB is restarted, it checks its ``_replicator`` database and
-restarts any replication that is described by a document that either has
-its ``_replication_state`` field set to ``triggered`` or it doesn't have
-yet the ``_replication_state`` field set.
-
- **Note**
-
- Continuous replications always have a ``_replication_state`` field
- with the value ``triggered``, therefore they're always restarted
- when CouchDB is restarted.
-
-Changing the Replicator Database
---------------------------------
-
-Imagine your replicator database (default name is \_replicator) has the
-two following documents that represent pull replications from servers A
-and B:
-
-::
-
- {
- "_id": "rep_from_A",
- "source": "http://aserver.com:5984/foo",
- "target": "foo_a",
- "continuous": true,
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280",
- "_replication_state": "triggered",
- "_replication_state_time": 1297971311
- }
- {
- "_id": "rep_from_B",
- "source": "http://bserver.com:5984/foo",
- "target": "foo_b",
- "continuous": true,
- "_replication_id": "231bb3cf9d48314eaa8d48a9170570d1",
- "_replication_state": "triggered",
- "_replication_state_time": 1297974122
- }
-
-Now without stopping and restarting CouchDB, you change the name of the
-replicator database to ``another_replicator_db``:
-
-::
-
- $ curl -X PUT http://localhost:5984/_config/replicator/db -d '"another_replicator_db"'
- "_replicator"
-
-As soon as this is done, both pull replications defined before, are
-stopped. This is explicitly mentioned in CouchDB's log:
-
-::
-
- [Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.104.0>] Stopping all ongoing replications because the replicator database was deleted or changed
- [Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.127.0>] 127.0.0.1 - - PUT /_config/replicator/db 200
-
-Imagine now you add a replication document to the new replicator
-database named ``another_replicator_db``:
-
-::
-
- {
- "_id": "rep_from_X",
- "source": "http://xserver.com:5984/foo",
- "target": "foo_x",
- "continuous": true
- }
-
-From now own you have a single replication going on in your system: a
-pull replication pulling from server X. Now you change back the
-replicator database to the original one ``_replicator``:
-
-::
-
- $ curl -X PUT http://localhost:5984/_config/replicator/db -d '"_replicator"'
- "another_replicator_db"
-
-Immediately after this operation, the replication pulling from server X
-will be stopped and the replications defined in the \_replicator
-database (pulling from servers A and B) will be resumed.
-
-Changing again the replicator database to ``another_replicator_db`` will
-stop the pull replications pulling from servers A and B, and resume the
-pull replication pulling from server X.
-
-Replicating the replicator database
------------------------------------
-
-Imagine you have in server C a replicator database with the two
-following pull replication documents in it:
-
-::
-
- {
- "_id": "rep_from_A",
- "source": "http://aserver.com:5984/foo",
- "target": "foo_a",
- "continuous": true,
- "_replication_id": "c0ebe9256695ff083347cbf95f93e280",
- "_replication_state": "triggered",
- "_replication_state_time": 1297971311
- }
- {
- "_id": "rep_from_B",
- "source": "http://bserver.com:5984/foo",
- "target": "foo_b",
- "continuous": true,
- "_replication_id": "231bb3cf9d48314eaa8d48a9170570d1",
- "_replication_state": "triggered",
- "_replication_state_time": 1297974122
- }
-
-Now you would like to have the same pull replications going on in server
-D, that is, you would like to have server D pull replicating from
-servers A and B. You have two options:
-
-- Explicitly add two documents to server's D replicator database
-
-- Replicate server's C replicator database into server's D replicator
- database
-
-Both alternatives accomplish exactly the same goal.
-
-Delegations
------------
-
-Replication documents can have a custom ``user_ctx`` property. This
-property defines the user context under which a replication runs. For
-the old way of triggering replications (POSTing to ``/_replicate/``),
-this property was not needed (it didn't exist in fact) - this is because
-at the moment of triggering the replication it has information about the
-authenticated user. With the replicator database, since it's a regular
-database, the information about the authenticated user is only present
-at the moment the replication document is written to the database - the
-replicator database implementation is like a \_changes feed consumer
-(with ``?include_docs=true``) that reacts to what was written to the
-replicator database - in fact this feature could be implemented with an
-external script/program. This implementation detail implies that for non
-admin users, a ``user_ctx`` property, containing the user's name and a
-subset of his/her roles, must be defined in the replication document.
-This is ensured by the document update validation function present in
-the default design document of the replicator database. This validation
-function also ensure that a non admin user can set a user name property
-in the ``user_ctx`` property that doesn't match his/her own name (same
-principle applies for the roles).
-
-For admins, the ``user_ctx`` property is optional, and if it's missing
-it defaults to a user context with name null and an empty list of roles
-- this mean design documents will not be written to local targets. If
-writing design documents to local targets is desired, the a user context
-with the roles ``_admin`` must be set explicitly.
-
-Also, for admins the ``user_ctx`` property can be used to trigger a
-replication on behalf of another user. This is the user context that
-will be passed to local target database document validation functions.
-
- **Note**
-
- The ``user_ctx`` property only has effect for local endpoints.
-
-Example delegated replication document:
-
-::
-
- {
- "_id": "my_rep",
- "source": "http://bserver.com:5984/foo",
- "target": "bar",
- "continuous": true,
- "user_ctx": {
- "name": "joe",
- "roles": ["erlanger", "researcher"]
- }
- }
-
-As stated before, for admins the user\_ctx property is optional, while
-for regular (non admin) users it's mandatory. When the roles property of
-``user_ctx`` is missing, it defaults to the empty list ``[ ]``.
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/1.1/ssl.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/1.1/ssl.rst b/share/docs/sphinx-docs/1.1/ssl.rst
deleted file mode 100644
index 5805ac9..0000000
--- a/share/docs/sphinx-docs/1.1/ssl.rst
+++ /dev/null
@@ -1,97 +0,0 @@
-Native SSL Support
-==================
-
-CouchDB 1.1 supports SSL natively. All your secure connection needs can
-now be served without the need set and maintain a separate proxy server
-that handles SSL.
-
-SSL setup can be tricky, but the configuration in CouchDB was designed
-to be as easy as possible. All you need is two files; a certificate and
-a private key. If you bought an official SSL certificate from a
-certificate authority, both should be in your possession already.
-
-If you just want to try this out and don't want to pay anything upfront,
-you can create a self-signed certificate. Everything will work the same,
-but clients will get a warning about an insecure certificate.
-
-You will need the OpenSSL command line tool installed. It probably
-already is.
-
-::
-
- shell>
- shell>
- shell>
- shell>
- mycert.pem privkey.pem
-
-Now, you need to edit CouchDB's configuration, either by editing your
-``local.ini`` file or using the ``/_config`` API calls or the
-configuration screen in Futon. Here is what you need to do in
-``local.ini``, you can infer what needs doing in the other places.
-
-Be sure to make these edits. Under ``[daemons]`` you should see:
-
-::
-
- ; enable SSL support by uncommenting the following line and supply the PEM's below.
- ; the default ssl port CouchDB listens on is 6984
- ;httpsd = {couch_httpd, start_link, [https]}
-
-Here uncomment the last line:
-
-::
-
- httpsd = {couch_httpd, start_link, [https]}
-
-Next, under ``[ssl]`` you will see:
-
-::
-
- ;cert_file = /full/path/to/server_cert.pem
- ;key_file = /full/path/to/server_key.pem
-
-Uncomment and adjust the paths so it matches your system's paths:
-
-::
-
- cert_file = /home/jan/cert/mycert.pem
- key_file = /home/jan/cert/privkey.pem
-
-For more information please read
-`http://www.openssl.org/docs/HOWTO/certificates.txt`_.
-
-Now start (or restart) CouchDB. You should be able to connect to it
-using HTTPS on port 6984:
-
-::
-
- shell>
- curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
- error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
- More details here: http://curl.haxx.se/docs/sslcerts.html
-
- curl performs SSL certificate verification by default, using a "bundle"
- of Certificate Authority (CA) public keys (CA certs). If the default
- bundle file isn't adequate, you can specify an alternate file
- using the --cacert option.
- If this HTTPS server uses a certificate signed by a CA represented in
- the bundle, the certificate verification probably failed due to a
- problem with the certificate (it might be expired, or the name might
- not match the domain name in the URL).
- If you'd like to turn off curl's verification of the certificate, use
- the -k (or --insecure) option.
-
-Oh no what happened?! — Remember, clients will notify their users that
-your certificate is self signed. ``curl`` is the client in this case and
-it notifies you. Luckily you trust yourself (don't you?) and you can
-specify the ``-k`` option as the message reads:
-
-::
-
- shell>
- {"couchdb":"Welcome","version":"1.1.0"}
-
-All done.
-
-.. _`http://www.openssl.org/docs/HOWTO/certificates.txt`: http://www.openssl.org/docs/HOWTO/certificates.txt
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/Makefile
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/Makefile b/share/docs/sphinx-docs/Makefile
deleted file mode 100644
index e2a80c1..0000000
--- a/share/docs/sphinx-docs/Makefile
+++ /dev/null
@@ -1,153 +0,0 @@
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS =
-SPHINXBUILD = sphinx-build
-PAPER =
-BUILDDIR = build
-
-# Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
-
-.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
-
-help:
- @echo "Please use \`make <target>' where <target> is one of"
- @echo " html to make standalone HTML files"
- @echo " dirhtml to make HTML files named index.html in directories"
- @echo " singlehtml to make a single large HTML file"
- @echo " pickle to make pickle files"
- @echo " json to make JSON files"
- @echo " htmlhelp to make HTML files and a HTML help project"
- @echo " qthelp to make HTML files and a qthelp project"
- @echo " devhelp to make HTML files and a Devhelp project"
- @echo " epub to make an epub"
- @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
- @echo " latexpdf to make LaTeX files and run them through pdflatex"
- @echo " text to make text files"
- @echo " man to make manual pages"
- @echo " texinfo to make Texinfo files"
- @echo " info to make Texinfo files and run them through makeinfo"
- @echo " gettext to make PO message catalogs"
- @echo " changes to make an overview of all changed/added/deprecated items"
- @echo " linkcheck to check all external links for integrity"
- @echo " doctest to run all doctests embedded in the documentation (if enabled)"
-
-clean:
- -rm -rf $(BUILDDIR)/*
-
-html:
- $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
- $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-singlehtml:
- $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
- @echo
- @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-pickle:
- $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
- @echo
- @echo "Build finished; now you can process the pickle files."
-
-json:
- $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
- @echo
- @echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
- $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
- @echo
- @echo "Build finished; now you can run HTML Help Workshop with the" \
- ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
- $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
- @echo
- @echo "Build finished; now you can run "qcollectiongenerator" with the" \
- ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
- @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/CouchDB.qhcp"
- @echo "To view the help file:"
- @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/CouchDB.qhc"
-
-devhelp:
- $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
- @echo
- @echo "Build finished."
- @echo "To view the help file:"
- @echo "# mkdir -p $$HOME/.local/share/devhelp/CouchDB"
- @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/CouchDB"
- @echo "# devhelp"
-
-epub:
- $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
- @echo
- @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-latex:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo
- @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
- @echo "Run \`make' in that directory to run these through (pdf)latex" \
- "(use \`make latexpdf' here to do that automatically)."
-
-latexpdf:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through pdflatex..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-text:
- $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
- @echo
- @echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-man:
- $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
- @echo
- @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-texinfo:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo
- @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
- @echo "Run \`make' in that directory to run these through makeinfo" \
- "(use \`make info' here to do that automatically)."
-
-info:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo "Running Texinfo files through makeinfo..."
- make -C $(BUILDDIR)/texinfo info
- @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-gettext:
- $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
- @echo
- @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-changes:
- $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
- @echo
- @echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
- $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
- @echo
- @echo "Link check complete; look for any errors in the above output " \
- "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
- $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
- @echo "Testing of doctests in the sources finished, look at the " \
- "results in $(BUILDDIR)/doctest/output.txt."
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/api.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/api.rst b/share/docs/sphinx-docs/api.rst
deleted file mode 100644
index 7328ce1..0000000
--- a/share/docs/sphinx-docs/api.rst
+++ /dev/null
@@ -1,434 +0,0 @@
-===========
-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 ?.
-
-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
-?.
-
-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 ?.
-
-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
-?.
-
-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:
-
-::
-
- {
- "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. For
-more information, see ?.
-
-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 ``*/*``:
-
- ::
-
- GET /recipes HTTP/1.1
- Host: couchdb:5984
- Accept: */*
-
- The returned headers are:
-
- ::
-
- 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:
-
- ::
-
- GET /recipes HTTP/1.1
- Host: couchdb:5984
- Accept: application/json
-
- The headers returned include the ``application/json`` content type:
-
- ::
-
- Server: CouchDB/1.0.1 (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.
-
-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:
-
- ::
-
- "A String"
-
-- Boolean - a ``true`` or ``false`` value. You can use these strings
- directly. For example:
-
- ::
-
- { "value": true}
-
-- Array - a list of values enclosed in square brackets. For example:
-
- ::
-
- ["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:
-
- ::
-
- {
- "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
-``eval()`` 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). See ? .
-
-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:
-
- ::
-
- {"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.
-
-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 ? .
-
-- ``/db/doc``
-
- Document methods, those that create, store, update or delete CouchDB
- documents and their attachments. For more information, see ?.
-
-- ``/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 ?.
-
-- ``/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 ?.
-
-- ``/_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 ?.
-
-- ``/_config``
-
- Methods for getting, and settings, CouchDB configuration parameters.
- For more information, see ?.
-
-JSON Structure Reference
-========================
-
-The following appendix provides a quick reference to all the JSON
-structures that you can supply to CouchDB, or get in return to requests.
-
-JSON Structures
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/api/authn.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/api/authn.rst b/share/docs/sphinx-docs/api/authn.rst
deleted file mode 100644
index a1a2b60..0000000
--- a/share/docs/sphinx-docs/api/authn.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-======================
-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:
-
-Authentication API Calls
http://git-wip-us.apache.org/repos/asf/couchdb/blob/010be920/share/docs/sphinx-docs/api/configuration.rst
----------------------------------------------------------------------
diff --git a/share/docs/sphinx-docs/api/configuration.rst b/share/docs/sphinx-docs/api/configuration.rst
deleted file mode 100644
index 48af41a..0000000
--- a/share/docs/sphinx-docs/api/configuration.rst
+++ /dev/null
@@ -1,216 +0,0 @@
-=====================
-Configuration Methods
-=====================
-
-The CouchDB API Server Configuration Methods provide an interface to
-query and update the various configuration values within a running
-CouchDB instance.
-
-``GET /_config``
-================
-
-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:
-
-::
-
- GET http://couchdb:5984/_config
- Accept: application/json
-
-The response is the JSON structure:
-
-::
-
- {
- "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``
-========================
-
-Gets the configuration structure for a single section. For example, to
-retrieve the CouchDB configuration section values:
-
-::
-
- GET http://couchdb:5984/_config/couchdb
- Accept: application/json
-
-The returned JSON contains just the configuration values for this
-section:
-
-::
-
- {
- "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``
-============================
-
-Gets a single configuration value from within a specific configuration
-section. For example, to obtain the current log level:
-
-::
-
- GET http://couchdb:5984/_config/log/level
- Accept: application/json
-
-Returns the string of the log level:
-
-::
-
- "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.
-
-``PUT /_config/section/key``
-============================
-
-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:
-
-::
-
- 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``
-===============================
-
-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:
-
-::
-
- DELETE http://couchdb:5984/_config/uuids/algorithm
- Content-Type: application/json
-
-The returned value is the last configured UUID function:
-
-::
-
- "random"