RELEASE: Update CHANGELOG, replace some occurrences of "HeartDB"

CHANGELOG.md

@@ -32,6 +32,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+* The default session timeout changed from 10 min to 60 min. Please set it to
+  your needs via the server config option `SESSION_TIMEOUT_MS`.
+
 ### Deprecated
 
 ### Removed

README_SETUP.md

@@ -80,7 +80,7 @@ server:
      Replace `localhost` by your host name, if you want.
    - `keytool -importkeystore -srckeystore caosdb.jks -destkeystore caosdb.p12 -deststoretype PKCS12 -srcalias selfsigned`
    - Export the public part only: `openssl pkcs12 -in caosdb.p12 -nokeys -out cert.pem`.
-	 The resulting `cert.pem` can safely be given to users to allow ssl verification.
+     The resulting `cert.pem` can safely be given to users to allow ssl verification.
    - You can check the content of the certificate with `openssl x509 -in cert.pem -text`
 
    Alternatively, you can create a keystore from certificate files that you already have:
@@ -93,14 +93,14 @@ server:
    appropriately:
     * Setup for MySQL back-end:
       specify the fields `MYSQL_USER_NAME`, `MYSQL_USER_PASSWORD`,
-	  `MYSQL_DATABASE_NAME`, and `MYSQL_HOST`.
+      `MYSQL_DATABASE_NAME`, and `MYSQL_HOST`.
     * Choose the ports under which CaosDB will be accessible.
     * Setup the SSL certificate: Assuming that there is an appropriate `Java Key
       Store` file (see above), change the fields `CERTIFICATES_KEY_PASSWORD`,
       `CERTIFICATES_KEY_STORE_PATH`, and `CERTIFICATES_KEY_STORE_PASSWORD`.
       Make sure that the conf file is not readable by other users because the
       certificate passwords are stored in plaintext.
-	- Set the path to the authtoken config (see step 4)
+    - Set the path to the authtoken config (see step 4)
     * Set the file system paths:
       - `FILE_SYSTEM_ROOT`: The root for all the files managed by CaosDB.
       - `DROP_OFF_BOX`: Files can be put here for insertion into CaosDB.
@@ -121,7 +121,7 @@ server:
     * See also [README_CONFIGURATION.md](README_CONFIGURATION.md)
 6. Copy `conf/core/usersources.ini.template` to `conf/ext/usersources.ini`.
     * You can skip this if you do not want to use an external authentication. 
-	  Local users (CaosDB realm) are always available.
+      Local users (CaosDB realm) are always available.
     * Define the users/groups who you want to include/exclude.
     * Assign at least one user the `administration` role.
       * For example, if the admin user is called `caosdb`, there should be the

conf/core/server.conf

@@ -68,7 +68,7 @@ MYSQL_USER_NAME=caosdb
 # Password for the user
 MYSQL_USER_PASSWORD=caosdb
 # Schema of mysql procedures and tables which is required by this CaosDB instance. The versioning follows SemVer 2.0 specs.
-MYSQL_SCHEMA_VERSION=v5.0
+MYSQL_SCHEMA_VERSION=v4.0.0
 
 
 # --------------------------------------------------

src/doc/specification/AbstractProperty.md

@@ -5,8 +5,10 @@
 
 # AbstractProperty Specification
 
+**Warning:** This specification is outdated. It is included to serve as a starting point for a more up-to-date description of the `Property` entity.
+
 ## Introduction
-An `AbstractProperty` is one of the basal objects of HeartDB.
+An `AbstractProperty` is one of the basal objects of CaosDB.
 An `AbstractProperty` MUST have the following _qualities_ (shortcut in brackets):
 * a persistent id (`id`)
 * an unique name (`name`)
@@ -39,7 +41,7 @@ An `AbstractProperty` is represented in xml by a `<Property/>` tag. It's _qualit
 Depending on the purpose of the xml document (shall it represent an object in the database or an object _to be posted _to the database?) the `<Property/>` tag may actually have just a few of the mentioned "quality-attributes".
 
 ### GET AbstractProperty
-Any xml representation of an `AbstractProperty` that is retrieved from the HeartDB Server MUST have exactly ONE of the following forms, depending on the `AbstractProperty's` type:
+Any xml representation of an `AbstractProperty` that is retrieved from the CaosDB Server MUST have exactly ONE of the following forms, depending on the `AbstractProperty's` type:
 #### text
 
         <Property id="$id" name="$name" description="$description" generator="$generator" creator="$creator" created="$created" type="text" />
@@ -59,10 +61,10 @@ Any xml representation of an `AbstractProperty` that is retrieved from the Heart
 
         <Property id="$id" name="$name" description="$description" generator="$generator" creator="$creator" created="$created" type="file" />
 '''General Notes:
-* If the called Property does not exist or if the Property called without permission, the HeartDB Server will return an Error.
+* If the called Property does not exist or if the Property called without permission, the CaosDB Server will return an Error.
 
 ### POST AbstractProperty
-Any xml representation of an `AbstractProperty` that is to be posted to the HeartDB server MUST have exactly ONE of the following forms, depending on the `AbstractProperty's` type:
+Any xml representation of an `AbstractProperty` that is to be posted to the CaosDB server MUST have exactly ONE of the following forms, depending on the `AbstractProperty's` type:
 #### text
 
         <Property name="$name" description="$description" generator="$generator" type="text" />
@@ -82,10 +84,10 @@ Any xml representation of an `AbstractProperty` that is to be posted to the Hear
 
         <Property name="$name" description="$description" generator="$generator" type="file" />
 *General Notes:*
-* The `AbstractProperty's` `id` and timestamp (`created`) will be generated by the HeartDB Server.
-* The `AbstractProperty's` creator will be determined by the HeartDB Server depending on it's policy configuration.
+* The `AbstractProperty's` `id` and timestamp (`created`) will be generated by the CaosDB Server.
+* The `AbstractProperty's` creator will be determined by the CaosDB Server depending on it's policy configuration.
 * Any given attribute beyond these will be *ignored*.
-* If the `<Property/>` tag isn't compliant with these the HeartDB Server will return an Error.
+* If the `<Property/>` tag isn't compliant with these the CaosDB Server will return an Error.
 
 ----
 ## Examples

src/doc/specification/Fileserver.md

 # Fileserver
 
 ## Info
-There are several ways to utilize the file server component of HeartDB. It is possible to upload a file or a whole folder including subfolders via HTTP and the _drop off box_. It is possible to download a file via HTTP identified by its ID or by its path in the internal file system. Furthermore, it is possible to get the files metadata via HTTP as an xml. 
+There are several ways to utilize the file server component of CaosDB. It is possible to upload a file or a whole folder including subfolders via HTTP and the _drop off box_. It is possible to download a file via HTTP identified by its ID or by its path in the internal file system. Furthermore, it is possible to get the files metadata via HTTP as an xml. 
 
 ## File upload
 ### Drop off box
 
-The drop off box is a directory on the HeartDB server's local file system, specified in the `server.conf` file in the server's basepath (something like `~/HeartDB/server/server.conf`). The key in the `server.conf` is called `dropoffbox`. Since the drop off box directory is writable for all, users can push their files or complete folders via a `mv` or a `cp` (recommended!) in that folder. The server deletes files older than their maximum lifetime (24 hours by default, specified `in server.conf`). But within their lifetime a user can prompt the server to pick up the file (or folder) from the drop off box in order to transfer it to the internal file system. 
+The drop off box is a directory on the CaosDB server's local file system, specified in the `server.conf` file in the server's basepath (something like `~/CaosDB/server/server.conf`). The key in the `server.conf` is called `dropoffbox`. Since the drop off box directory is writable for all, users can push their files or complete folders via a `mv` or a `cp` (recommended!) in that folder. The server deletes files older than their maximum lifetime (24 hours by default, specified `in server.conf`). But within their lifetime a user can prompt the server to pick up the file (or folder) from the drop off box in order to transfer it to the internal file system. 
 
 Now, the user may send a pick up request to `POST http://host:port/mpidsserver/FilesDropOff` with a similar body:
 
@@ -38,9 +38,9 @@ where
 There is an example on file upload using cURL described in detail in [the curl section of this
 documentation](../administration/curl-access.md).
 
-File upload via HTTP is implemented in a [rfc1867](http://www.ietf.org/rfc/rfc1867.txt) consistent way. This is a de-facto standard that defines a file upload as a part of an HTML form submission. This concept shall not be amplified here. But it has to be noticed that this protocol is not designed for uploads of complete structured folders. Therefore the HeartDB file components have to impose that structure on the upload protocol. 
+File upload via HTTP is implemented in a [rfc1867](http://www.ietf.org/rfc/rfc1867.txt) consistent way. This is a de-facto standard that defines a file upload as a part of an HTML form submission. This concept shall not be amplified here. But it has to be noticed that this protocol is not designed for uploads of complete structured folders. Therefore the CaosDB file components have to impose that structure on the upload protocol. 
 
-HeartDB's file upload resource does exclusively accept POST requests of MIME media type `multipart/form-data`. The first part of each POST body is expected to be a form-data text field, containing information about the files to be uploaded. It has to meet the following requirements:
+CaosDB's file upload resource does exclusively accept POST requests of MIME media type `multipart/form-data`. The first part of each POST body is expected to be a form-data text field, containing information about the files to be uploaded. It has to meet the following requirements:
 * `Content-type: text/plain; charset=UTF-8`
 * `Content-disposition: form-data; name="FileRepresentation"`
 

src/doc/specification/RecordType.md

 # RecordType
 
+**Warning:** This specification is outdated. It is included to serve as a starting point for a more up-to-date description of the `RecordType` entity.
+
 ## Overview
 RecordTypes function as templates for [[Record|Records]], they provide a description for a type of Record and define which [[Property|Properties]] should be present.  Properties come with an _importance_ attribute which tells the user or client program how strongly necessary the Property is.  (As all other entities,) RecordTypes can be inherited from other RecordTypes (or any Entities).  When RecordTypes inherit from other RecordTypes, the _inheritance_ flag tells which properties shall be inherited.