Merge remote-tracking branch 'origin/master' into 1.6

README.md

@@ -4,10 +4,9 @@
 
 http://tarantool.org
 
-Tarantool is an efficient NoSQL database and a
-Lua application server.
+Tarantool is an in-memory database and application server.
 
-Key features of the Lua application server:
+Key features of the application server:
  * 100% compatible drop-in replacement for Lua 5.1,
    based on LuaJIT 2.0.
    Simply use #!/usr/bin/tarantool instead of

doc/sphinx/book/administration.rst

@@ -87,7 +87,7 @@ sensitive so ``insert`` and ``Insert`` are not the same thing.
 String literals are: Any sequence of zero or more characters enclosed in
 single quotes. Double quotes are legal but single quotes are preferred.
 Enclosing in double square brackets is good for multi-line strings as
-described in `Lua documentation`_. Examples: 'Hello, world', 'A', [[A\B!]].
+described in `Lua documentation`_. Examples: 'Hello, world', 'A', [[A\\B!]].
 
 .. _Lua documentation: http://www.lua.org/pil/2.4.html
 

doc/sphinx/book/box/net_box.rst

+.. _package_net_box:
+
 -----------------------------------------------------------------------------------------
                             Package `net.box` -- working with networked Tarantool peers
 -----------------------------------------------------------------------------------------

doc/sphinx/book/box/triggers.rst

@@ -5,7 +5,7 @@
 -------------------------------------------------------------------------------
 
 Triggers, also known as callbacks, are functions which the server executes when
-certain events happen. Currently the two types of triggers are `connection triggers`_,
+certain events happen. Currently the main types of triggers are `connection triggers`_,
 which are executed when a session begins or ends, and `replace triggers`_ which are
 for database events,
 
@@ -13,12 +13,12 @@ All triggers have the following characteristics.
 
 * They associate a `function` with an `event`. The request to "define a trigger"
   consists of passing the name of the trigger's function to one of the
-  "on_`event-name` ..." functions: ``on_connect()``, ``on_disconnect()``,
-  or ``on_replace()``.
+  ":samp:`on_{event-name}()`" functions: :code:`on_connect()`, :code:`on_auth()`,
+  :code:`on_disconnect()`, or :code:`on_replace()`.
 * They are `defined by any user`. There are no privilege requirements for defining
   triggers.
 * They are called `after` the event. They are not called if the event ends
-  prematurely due to an error.
+  prematurely due to an error. (Exception: :code:`on_auth()` is called before the event.)
 * They are in `server memory`. They are not stored in the database. Triggers
   disappear when the server is shut down. If there is a requirement to make
   them permanent, then the function definitions and trigger settings should
@@ -109,6 +109,34 @@ Here is what might appear in the log file in a typical installation:
     2014-12-15 13:22:19.289 [11360] main/103/iproto I>
         Disconnection. user=guest id=3
 
+===========================================================
+                    Authentication triggers
+===========================================================
+
+.. function:: box.session.on_auth(trigger-function [, old-trigger-function-name])
+
+    Define a trigger for execution during authentication.
+    The on_auth trigger function is invoked after the on_connect trigger function,
+    if and only if the connection has succeeded so far.
+    For this purpose, connection and authentication are considered to be separate steps.
+
+    Unlike other trigger types, on_auth trigger functions are invoked `before`
+    the event. Therefore a trigger function like ":code:`function auth_function () v = box.session.user(); end`"
+    will set :code:`v` to "guest", the user name before the authentication is done.
+    To get the user name after the authentication is done, use the special syntax:
+    ":code:`function auth_function (user_name) v = user_name; end`"
+
+    If the trigger fails by raising an
+    error, the error is sent to the client and the connection is closed.
+
+    :param function trigger-function: function which will become the trigger function
+    :param function old-trigger-function: existing trigger function which will be replaced by trigger-function
+    :return: nil
+
+    If the parameters are (nil, old-trigger-function), then the old trigger is deleted.
+
+    Example: :codenormal:`function f () x = x + 1 end; box.session.on_auth(f)`
+
 
 ===========================================================
                     Replace triggers

doc/sphinx/book/user_guide_getting_started.rst

+-------------------------------------------------------------------------------
+                        Getting started
+-------------------------------------------------------------------------------
+
+
+If the installation has already been done, then you should try it out. So we've
+provided some instructions that you can use to make a temporary “sandbox”. In a
+few minutes you can start the server and type in some database-manipulation
+statements. The section about sandbox is “`Starting Tarantool and making your first database`_”.
+
+.. _first database:
+
+=====================================================================
+        Starting Tarantool and making your first database
+=====================================================================
+
+Here is how to create a simple test database after installing.
+
+Create a new directory. It's just for tests, you can delete it when the tests are over.
+
+ | :codebold:`mkdir` :codebolditalic:`~/tarantool_sandbox`
+ | :codebold:`cd` :codebolditalic:`~/tarantool_sandbox`
+
+Start the server. The server name is tarantool.
+
+ | :codebold:`#if you downloaded a binary with apt-get or yum, say this:`
+ | :codebold:`/usr/bin/tarantool`
+ | :codebold:`#if you downloaded and untarred a binary tarball to ~/tarantool, say this:`
+ | :codebold:`~/tarantool/bin/tarantool`
+ | :codebold:`#if you built from a source download, say this:`
+ | :codebold:`~/tarantool/src/tarantool`
+
+The server starts in interactive mode and outputs a command prompt.
+To turn on the database, :mod:`configure <box.cfg>` it:
+:codenormal:`tarantool>` :codebold:`box.cfg{listen=3301}`
+(this minimal example is sufficient).
+
+If all goes well, you will see the server displaying progress as it
+initializes, something like this:
+
+ | :codenormal:`tarantool> box.cfg{listen=3301}`
+ | :codenormal:`2014-08-07 09:41:41.077 ... version 1.6.3-439-g7e1011b`
+ | :codenormal:`2014-08-07 09:41:41.077 ... log level 5`
+ | :codenormal:`2014-08-07 09:41:41.078 ... mapping 1073741824 bytes for a shared arena...`
+ | :codenormal:`2014-08-07 09:41:41.079 ... initialized`
+ | :codenormal:`2014-08-07 09:41:41.081 ... initializing an empty data directory`
+ | :codenormal:`2014-08-07 09:41:41.095 ... creating './00000000000000000000.snap.inprogress'`
+ | :codenormal:`2014-08-07 09:41:41.095 ... saving snapshot './00000000000000000000.snap.inprogress'`
+ | :codenormal:`2014-08-07 09:41:41.127 ... done`
+ | :codenormal:`2014-08-07 09:41:41.128 ... primary: bound to 0.0.0.0:3301`
+ | :codenormal:`2014-08-07 09:41:41.128 ... ready to accept requests`
+
+Now that the server is up, you could start up a different shell
+and connect to its primary port with |br|
+:codebold:`telnet 0 3301` |br|
+but for example purposes it is simpler to just leave the server
+running in "interactive mode". On production machines the
+interactive mode is just for administrators, but because it's
+convenient for learning it will be used for most examples in
+this manual. Tarantool is waiting for the user to type instructions.
+
+To create the first space and the first :ref:`index <box.index>`, try this:
+
+ | :codenormal:`tarantool>` :codebold:`s = box.schema.space.create('tester')`
+ | :codenormal:`tarantool>` :codebold:`i = s:create_index('primary', {type = 'hash', parts = {1, 'NUM'}})`
+
+To insert three “tuples” (our name for “records”) into the first “space” of the database try this:
+
+ | :codenormal:`tarantool>` :codebold:`t = s:insert({1})`
+ | :codenormal:`tarantool>` :codebold:`t = s:insert({2, 'Music'})`
+ | :codenormal:`tarantool>` :codebold:`t = s:insert({3, 'Length', 93})`
+
+To select a tuple from the first space of the database, using the first defined key, try this:
+
+ | :codenormal:`tarantool>` :codebold:`s:select{3}`
+
+Your terminal screen should now look like this:
+
+ | :codenormal:`tarantool> s = box.schema.space.create('tester')`
+ | :codenormal:`2014-06-10 12:04:18.158 ... creating './00000000000000000002.xlog.inprogress'`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ | :codenormal:`tarantool> s:create_index('primary', {type = 'hash', parts = {1, 'NUM'}})`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ | :codenormal:`tarantool> t = s:insert{1}`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ | :codenormal:`tarantool> t = s:insert{2, 'Music'}`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ | :codenormal:`tarantool> t = s:insert{3, 'Length', 93}`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ | :codenormal:`tarantool> s:select{3}`
+ | :codenormal:`---`
+ | :codenormal:`- - [3, 'Length', 93]`
+ | :codenormal:`...`
+ |
+ | :codenormal:`tarantool>`
+
+Now, to prepare for the example in the next section, try this:
+
+ | :codenormal:`tarantool>` :codebold:`box.schema.user.grant('guest','read,write,execute','universe')`
+
+.. _tarantool.org/dist/stable: http://tarantool.org/dist/stable
+.. _tarantool.org/dist/master: http://tarantool.org/dist/master
+
+
+=====================================================================
+        Starting another Tarantool instance and connecting remotely
+=====================================================================
+
+In the previous section the first request was with "box.cfg{listen=3301}".
+The "listen" value can be any form of URI (uniform resource identifier);
+in this case it's just a local port: port 3301.
+It's possible to send requests to the listen URI via (a) telnet,
+(b) a connector (which will be the subject of Chapter 8),
+or (c) another instance of Tarantool. Let's try (c).
+
+Switch to another terminal.
+On Linux, for example, this means starting another instance of a Bash shell.
+There is no need to use cd to switch to the :codenormal:`~/tarantool_sandbox` directory.
+
+Start the second instance of Tarantool. The server name is tarantool.
+
+  | :codebold:`#if you downloaded a binary with apt-get or yum, say this:`
+  | :codebold:`/usr/bin/tarantool`
+  | :codebold:`#if you downloaded and untarred a binary tarball to ~/tarantool, say this:`
+  | :codebold:`~/tarantool/bin/tarantool`
+  | :codebold:`#if you built from a source download, say this:`
+  | :codebold:`~/tarantool/src/tarantool`
+
+Try these requests:
+
+  | :codebold:`console = require('console')`
+  | :codebold:`console.connect('localhost:3301')`
+  | :codebold:`box.space.tester:select{2}`
+
+The requests are saying "use the :ref:`console package <package-console>`
+to connect to the Tarantool server that's listening
+on localhost:3301, send a request to that server,
+and display the result." The result in this case is
+one of the tuples that was inserted earlier.
+Your terminal screen should now look like this:
+
+ | :codenormal:`...`
+ |
+ | :codenormal:`tarantool> console = require('console')`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ |
+ | :codenormal:`tarantool> console.connect('localhost:3301')`
+ | :codenormal:`2014-08-31 12:46:54.650 [32628] main/101/interactive I> connected to localhost:3301`
+ | :codenormal:`---`
+ | :codenormal:`...`
+ |
+ | :codenormal:`localhost:3301> box.space.tester:select{2}`
+ | :codenormal:`---`
+ | :codenormal:`- - [2, 'Music']`
+ | :codenormal:`...`
+ |
+ | :codenormal:`localhost:3301>`
+
+You can repeat box.space...:insert{} and box.space...:select{}
+indefinitely, on either Tarantool instance.
+When the testing is over: To drop the space: :codenormal:`s:drop()`.
+To stop tarantool: :codenormal:`Ctrl+C`. To stop tarantool (an alternative):
+:codenormal:`os.exit()`. To stop tarantool (from another terminal):
+:codebold:`sudo pkill -f` :codebolditalic:`tarantool`.
+To destroy the test: :codebold:`rm -r` :codebolditalic:`~/tarantool_sandbox`.
+
+To review ... If you followed all the instructions
+in this chapter, then so far you have: installed Tarantool
+from either a binary or a source repository,
+started up the Tarantool server, inserted and selected tuples.
+

doc/sphinx/dev_guide/building_from_source.rst

@@ -16,7 +16,7 @@ explain what the steps are, then on the Internet you can look at some example sc
      end in `-src.tar.gz`), the latest complete source downloads are on github.com, and
      from github one gets with git.
 
-   * A C/C++ compiler. |br| Ordinarily the compiler is ``GCC`` version 4.6 or later, on
+   * A C/C++ compiler. |br| Ordinarily the compiler is `gcc` and ``g++`` version 4.6 or later, on
      Mac OS X it should be ``Clang`` version 3.2 or later.
 
    * A program for managing the build process. |br| This is always ``CMake``
@@ -25,33 +25,20 @@ explain what the steps are, then on the Internet you can look at some example sc
    Here are names of tools and libraries which may have to be installed in advance,
    using ``sudo apt-get`` (for Ubuntu), ``sudo yum install`` (for CentOS), or the
    equivalent on other platforms. Different platforms may use slightly different
-   names. Do not worry about the ones marked `optional, for build with -DENABLE_DOC`
-   unless you intend to work on the documentation.
+   names. Do not worry about the ones marked `optional, only in Mac OS scripts`
+   unless your platform is Mac OS.
 
-   * **binutils-dev** or **binutils-devel**   # contains GNU BFD for printing stack traces
-   * **gcc or clang**                         # see above
+   * **gcc and g++, or clang**                # see above
    * **git**                                  # see above
    * **cmake**                                # see above
-   * **libreadline-dev**                      # for interactive mode
-   * **libncurses5-dev** or **ncurses-devel** # see above
-   * **xsltproc**                             # optional, for build with -DENABLE_DOC
-   * **lynx**                                 # optional, for build with -DENABLE_DOC
-   * **jing**                                 # optional, for build with -DENABLE_DOC
-   * **libxml2-utils**                        # optional, for build with -DENABLE_DOC
-   * **docbook5-xml**                         # optional, for build with -DENABLE_DOC
-   * **docbook-xsl-ns**                       # optional, for build with -DENABLE_DOC
-   * **w3c-sgml-lib**                         # optional, for build with -DENABLE_DOC
-   * **libsaxon-java**                        # optional, for build with -DENABLE_DOC
-   * **libxml-commons-resolver1.1-java**      # optional, for build with -DENABLE_DOC
-   * **libxerces2-java**                      # optional, for build with -DENABLE_DOC
-   * **libxslthl-java**                       # optional, for build with -DENABLE_DOC
-   * **autoconf**                             # optional, appears only in Mac OS scripts
-   * **zlib1g** or **zlib**                   # optional, appears only in Mac OS scripts
+   * **libreadline-dev or libreadline6-dev**  # for interactive mode
+   * **autoconf**                             # optional, only in Mac OS scripts
+   * **zlib1g** or **zlib**                   # optional, only in Mac OS scripts
 
 2. Set up python modules for running the test suite or creating documentation.
    This step is optional. Python modules are not necessary for building Tarantool
-   itself, unless one intends to use the ``-DENABLE_DOC`` option in step 6 or the
-   "Run the test suite" option in step 8. Say:
+   itself, unless one intends to use the ``-DENABLE_DOC`` option in step 5 or the
+   "Run the test suite" option in step 7. Say:
 
    .. code-block:: bash
 
@@ -64,19 +51,21 @@ explain what the steps are, then on the Internet you can look at some example sc
 
    .. code-block:: bash
 
+     # For both test suite and documentation
+     sudo apt-get install python-pip python-dev python-yaml
      # For test suite
-     sudo apt-get install python-daemon python-yaml python-argparse
+     sudo apt-get install python-daemon
      # For documentation
-     sudo apt-get install python-jinja2 python-markdown
-
+     sudo apt-get install python-sphinx python-pelican python-beautifulsoup
 
    On CentOS too you can get modules from the repository:
 
    .. code-block:: bash
 
-     sudo yum install python26 python26-PyYAML python26-argparse
+     sudo yum install python26 python26-PyYAML etc.
 
-   But in general it is best to set up the modules by getting a tarball and
+   If modules are not available on a repository,
+   it is best to set up the modules by getting a tarball and
    doing the setup with ``python setup.py``, thus:
 
    .. code-block:: bash
@@ -100,20 +89,6 @@ explain what the steps are, then on the Internet you can look at some example sc
      cd python-daemon-1.5.5
      sudo python setup.py install
 
-     # python module for text-to-html conversion (markdown):
-     # For documentation: (If wget fails, check the
-     # http://pypi.python.org/pypi/Markdown/
-     # to see what the current version is.)
-     cd ~
-     wget https://pypi.python.org/packages/source/M/Markdown/Markdown-2.3.1.tar.gz
-     tar -xzvf Markdown-2.3.1.tar.gz
-     cd Markdown-2.3.1
-     sudo python setup.py install
-
-     # python module which includes Jinja2 template engine:
-     # For documentation:
-     sudo pip install pelican
-
      # python module for HTML scraping: For documentation:
      cd ~
      wget http://www.crummy.com/software/BeautifulSoup/bs3/download//3.x/BeautifulSoup-3.2.1.tar.gz
@@ -121,7 +96,26 @@ explain what the steps are, then on the Internet you can look at some example sc
      cd BeautifulSoup-3.2.1
      sudo python setup.py install
 
-5. Use ``git`` again so that third-party contributions will be seen as well.
+   Finally, use Python :code:`pip` to bring in Python packages
+   that may not be up-to-date in the distro repositories.
+
+   .. code-block:: bash
+
+     # For test suite
+     pip install tarantool\>0.4 --user
+     # For documentation
+     sudo pip install pelican
+     sudo pip install -U sphinx
+
+3. Use :code:`git` to download the latest source code from the
+   Tarantool 1.6 master branch on github.com.
+
+   .. code-block:: bash
+
+     cd ~
+     git clone https://github.com/tarantool/tarantool.git ~/tarantool
+
+4. Use ``git`` again so that third-party contributions will be seen as well.
    This step is only necessary once, the first time you do a download. There
    is an alternative -- say ``git clone --recursive`` in step 3 -- but we
    prefer this method because it works with older versions of ``git``.
@@ -136,7 +130,7 @@ explain what the steps are, then on the Internet you can look at some example sc
    On rare occasions, the submodules will need to be updated again with the
    command: ``git submodule update --init --recursive``.
 
-6. Use CMake to initiate the build.
+5. Use CMake to initiate the build.
 
    .. code-block: bash
 
@@ -145,19 +139,27 @@ explain what the steps are, then on the Internet you can look at some example sc
      rm CMakeCache.txt  # unnecessary, added for good luck
      cmake .            # Start build with build type=Debug, no doc
 
-   The option for specifying build type is ``-DCMAKE_BUILD_TYPE=<type>`` where
-   ``type = <None | Debug | Release | RelWithDebInfo | MinSizeRel>`` and a
+   On some platforms it may be necessary to specify the C and C++ versions,
+   for example
+
+   .. code-block: bash
+
+     CC=gcc-4.8 CXX=g++-4.8 cmake .
+
+   The option for specifying build type is :samp:`-DCMAKE_BUILD_TYPE={type}` where
+   :samp:`{type} = None | Debug | Release | RelWithDebInfo | MinSizeRel` and a
    reasonable choice for production is ``-DCMAKE_BUILD_TYPE=RelWithDebInfo``
    (``Debug`` is used only by project maintainers and ``Release`` is used only
    when the highest performance is required).
 
-   The option for asking to build documentation is ``-DENABLE_DOC=<true|false>``
-   and the assumption is that only a minority will need to rebuild the
-   documentation (such as what you're reading now), so details about
-   documentation are in the developer manual, and the reasonable choice
+   The option for asking to build documentation is ``-DENABLE_DOC=true|false`,
+   which outputs HTML documentation (such as what you're reading now) to the
+   subdirectory doc/www/output/doc. Tarantool uses the Sphinx simplified markup system.
+   Since most users do not need to rebuild the documentation,
+   the reasonable option
    is ``-DENABLE_DOC=false`` or just don't use the ``-DENABLE_DOC`` clause at all.
 
-7. Use make to complete the build.
+6. Use make to complete the build.
 
    .. code-block:: bash
 
@@ -165,7 +167,7 @@ explain what the steps are, then on the Internet you can look at some example sc
 
    It's possible to say ``make install`` too, but that's not generally done.
 
-8. Run the test suite. This step is optional. |br| Tarantool's developers always
+7. Run the test suite. This step is optional. |br| Tarantool's developers always
    run the test suite before they publish new versions. You should run the test
    suite too, if you make any changes in the code. Assuming you downloaded to
    ``~/tarantool``, the principal steps are:
@@ -208,10 +210,9 @@ explain what the steps are, then on the Internet you can look at some example sc
      rmdir ~/tarantool/bin
 
 
-9. Make an rpm. |br| This step is optional. It's only for people who want to
+8. Make an rpm. |br| This step is optional. It's only for people who want to
    redistribute Tarantool. Package maintainers who want to build with rpmbuild
-   should consult the
-   :doc:`Tarantool Developer Guide <index>`
+   should consult the rpm-build instructions for the appropriate platform.
 
 This is the end of the list of steps to take for source downloads.
 
@@ -229,49 +230,5 @@ For your added convenience, github.com has README files with example scripts:
 These example scripts assume that the intent is to download from the master
 branch, build the server (but not the documentation), and run tests after build.
 
-To build with SUSE 13.1, the steps are as described above, except that the
-appropriate YaST2 package names are: binutils-devel, cmake, ncurses-devel,
-lynx, jing, libxml2-devel, docbook_5, saxon, libxslt-devel. |br|
 The python connector can be installed with ``sudo easy_install pip`` and ``sudo pip install tarantool``.
 
-===========================================================
-                How to build the XML manual
-===========================================================
-
-To build XML manual, you'll need:
-
-* xsltproc
-* docbook5-xml
-* docbook-xsl-ns
-* w3c-sgml-lib
-* libsaxon-java (for saxon processing)
-* libxml-commons-resolver1.1-java
-* libxml2-utils
-* libxerces2-java
-* libxslthl-java
-* lynx
-* jing
-
-When all pre-requisites are met, you should run:
-
-.. code-block:: bash
-
-    $ cmake . -DENABLE_DOC=YES
-
-to enable documentation builder.
-
-If you want to make tarantool user guide, you should run the
-following command from tarantool root directory:
-
-.. code-block:: bash
-
-    $ make html
-
-or
-
-.. code-block:: bash
-
-    $ cd doc/user
-    $ make
-
-The html version of the user guide will be generated in doc/www/content/doc

doc/sphinx/getting_started.rst

@@ -197,7 +197,7 @@ and make install.
 
 .. _tarantool.org/dist/master/tarantool.rb: http://tarantool.org/dist/master/tarantool.rb
 
-.. _first database:
+.. _dup first database:
 
 =====================================================================
         Starting Tarantool and making your first database

doc/sphinx/reference/expirationd.rst

@@ -68,7 +68,7 @@ For those who like to see things run, here are the exact steps to get
 expirationd through the test.
 
 1. Get ``expirationd.lua``. There are standard ways - it is after all part
-   of a standard rock - but for this purpose just copy the contents of
+   of a `standard rock <https://luarocks.org/modules/rtsisyk/expirationd>`_  - but for this purpose just copy the contents of
    expirationd.lua_ to a default directory.
 2. Start the Tarantool server as described before.
 3. Execute these requests:

doc/sphinx/reference/fiber.rst

@@ -83,7 +83,7 @@ can be reused when another fiber is created.
 
     Return information about all fibers.
 
-    :return: the name, id, and backtrace of all fibers.
+    :return: the name, id, available memory, used memory, and backtrace of all fibers.
     :rtype: table
 
 .. function:: kill(id)

doc/sphinx/reference/socket.rst

@@ -88,7 +88,7 @@ the function invocations will look like ``sock:function_name(...)``.
 .. function:: __call(domain, type, protocol)
 
     Create a new TCP or UDP socket. The argument values
-    are the same as in the `Linux man page <http://man7.org/linux/man-pages/man2/socket.2.html>`_.
+    are the same as in the `Linux socket(2) man page <http://man7.org/linux/man-pages/man2/socket.2.html>`_.
 
     :param domain:
     :param type:
@@ -151,7 +151,7 @@ the function invocations will look like ``sock:function_name(...)``.
     .. method:: sysconnect(host, port)
 
         Connect a socket to a remote host. The argument values are the same as
-        in the Linux man page [1]_.
+        in the `Linux connect(2) man page <http://man7.org/linux/man-pages/man2/connect.2.html>`_.
         The host must be an IP address.
 
         Parameters:
@@ -333,7 +333,7 @@ the function invocations will look like ``sock:function_name(...)``.
     .. method:: setsockopt(level, name, value)
 
         Set socket flags. The argument values are the same as in the
-        Linux man page [2]_.
+        `Linux getsockopt(2) man page <http://man7.org/linux/man-pages/man2/setsockopt.2.html>`_.
         The ones that Tarantool accepts are:
 
             * SO_ACCEPTCONN
@@ -372,7 +372,7 @@ the function invocations will look like ``sock:function_name(...)``.
     .. method:: linger([active])
 
         Set or clear the SO_LINGER flag. For a description of the flag, see
-        Linux man page [3]_.
+        the `Linux man page <http://man7.org/linux/man-pages/man1/loginctl.1.html>`_.
 
         :param boolean active:
 
@@ -561,7 +561,4 @@ The strings "A", "B", "C" are printed.
 
 .. _luasocket: https://github.com/diegonehab/luasocket
 
-.. [1] http://man7.org/linux/man-pages/man2/connect.2.html
-.. [2] http://man7.org/linux/man-pages/man2/setsockopt.2.html
-.. [3] http://man7.org/linux/man-pages/man1/loginctl.1.html
 

doc/www/content/newsite/index.yml

@@ -6,10 +6,7 @@ template: "index"
 blocks  :
   header:
     - "Tarantool"
-    - "A NoSQL database running in a Lua application server"
-    - >
-      Tarantool combines the network programming power of Node.JS
-      with data persitence capabilities of Redis.
+    - "Get your data in RAM. Get compute close to data. Enjoy the performance"
   features:
     - format: rst
       content: >
@@ -27,9 +24,9 @@ blocks  :
         MessagePack based client-server protocol
     - format: rst
       content: >
-        two data engines: 100% in-memory with optional persistence
-        and a `2-level disk-based B-tree <http://sphia.org>`_,
-        to use with large data sets
+        a built-in database with two data engines: 100% in-memory
+        with optional persistence and a `2-level disk-based B-tree
+        <http://sphia.org>`_, to use with large data sets
     - "secondary key and index iterators support"
     - "asynchronous master-master replication"
     - "authentication and access control"