Change (ocis,OCIS) to oCIS, unify GitHub branding

docs/extensions/glauth/_index.md

@@ -8,6 +8,6 @@ geekdocFilePath: _index.md
 geekdocCollapseSection: true
 ---
 
-This service provides a [glauth](https://github.com/glauth/glauth) based LDAP proxy for ocis which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the ocis accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.
+This service provides a [glauth](https://github.com/glauth/glauth) based LDAP proxy for oCIS which can be used by clients or other extensions. It allows applications relying on LDAP to access the accounts stored in the oCIS accounts service. It can be used to make firewalls or identity providers aware of all users, including guest accounts.
 
 We are using it to make eos aware of all accounts so the native ACLs can be used to persist share information in the storage.

docs/extensions/settings/glossary.md

@@ -39,4 +39,4 @@ In the context of this extension and oCIS in general, we are using the following
 - Manifestation of a setting for a specific user
 - E.g. used for customization (at runtime) in `ocis-web`
 - `ocis-web-settings` extension for modifying settings values is provided by this service
-- Can be queried and modified by other ocis extensions
+- Can be queried and modified by other oCIS extensions

docs/extensions/storage/_index.md

@@ -8,7 +8,7 @@ geekdocFilePath: _index.md
 geekdocCollapseSection: true
 ---
 
-This service provides an ocis extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
+This service provides an oCIS extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
 
 It uses the port range 9140-9179 to preconfigure several services.
 
@@ -43,4 +43,4 @@ It uses the port range 9140-9179 to preconfigure several services.
 | 9165      | storage oc data debug                         |
 | 9166-9177 | reserved for s3, wnd, custom + data providers |
 | 9178      | storage public link                           |
-| 9179      | storage public link data                      |
+| 9179      | storage public link data                      |

docs/extensions/storage/storages.md

@@ -13,11 +13,11 @@ geekdocFilePath: storages.md
 
 ## Storage providers
 
-To manage the file tree ocis uses storage *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
+To manage the file tree oCIS uses *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
 
 
 {{< hint info >}}
-While the *storage provider* is responsible for managing the tree, file up and download is delegated to a dedicated *data provider*. See below.
+While the *storage provider* is responsible for managing the tree, file up- and downloads are delegated to a dedicated *data provider*. See below.
 {{< /hint >}}
 
 ## Storage aspects