From 199de9a3cceed546c384d3ad575ba528286fdb6b Mon Sep 17 00:00:00 2001 From: Phil Davis Date: Mon, 13 Jun 2022 12:39:08 +0545 Subject: [PATCH] [docs-only] Minor docs edits --- docs/architecture/efficient-stat-polling.md | 2 +- docs/architecture/protocol-changes.md | 24 ++++++++++----------- docs/extensions/app-registry/apps.md | 2 +- docs/extensions/graph/groups.md | 8 +++---- docs/extensions/graph/users.md | 14 ++++++------ docs/extensions/storage/terminology.md | 2 +- docs/ocis/deployment/bridge.md | 4 ++-- docs/ocis/storage-backends/cephfs.md | 4 ++-- 8 files changed, 30 insertions(+), 30 deletions(-) diff --git a/docs/architecture/efficient-stat-polling.md b/docs/architecture/efficient-stat-polling.md index efd8ce9d42..e00d0d4155 100644 --- a/docs/architecture/efficient-stat-polling.md +++ b/docs/architecture/efficient-stat-polling.md @@ -123,7 +123,7 @@ graph TD {{}} -But how can maries client detect the change? +But how can Marie's client detect the change? We are trading writes for reads: the client needs to stat the own tree & all shares or entry points into other storage trees. diff --git a/docs/architecture/protocol-changes.md b/docs/architecture/protocol-changes.md index 1ed1310ad5..ab17e39e78 100644 --- a/docs/architecture/protocol-changes.md +++ b/docs/architecture/protocol-changes.md @@ -79,10 +79,10 @@ sequenceDiagram participant proxy participant ocDAV1 as ocDAV [a-k] participant ocDAV2 as ocDAV [l-z] - + Note right of Client: {spaceid} identifies the space
{relative/path} is relative to the space root Client->>+proxy: PROPFIND /dav/space/{spaceid}/{relative/path} - + alt username starting with a-k proxy->>+ocDAV1: PROPFIND /dav/space/{spaceid}/{relative/path} Note right of ocDAV1: translate ownCloud flavoured webdav
into CS3 API requests @@ -105,8 +105,8 @@ sequenceDiagram participant ocDAV participant Gateway participant StorageRegistry - participant StorageProvider1 as StoregeProvider [a-k] - participant StorageProvider2 as StoregeProvider [l-z] + participant StorageProvider1 as StorageProvider [a-k] + participant StorageProvider2 as StorageProvider [l-z] Note right of ocDAV: translate ownCloud flavoured webdav
into CS3 API requests ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path}) @@ -120,7 +120,7 @@ sequenceDiagram else username starting with l-z Gateway->>+StorageProvider2: ListContainer({spaceid}, path: {relative/path}) StorageProvider2-->>-Gateway: []ResourceInfo - end + end Gateway-->>-ocDAV: []ResourceInfo {{}} @@ -129,7 +129,7 @@ sequenceDiagram **PROPFIND request against old webdav endpoints** -To route a PROPFIND request against the old webdav endpoints like `/dav/files/username`, ocdav first has to build a CS3 namespace prefix, eg. `/users/{{.Id.OpaqueId}}` to the users home. +To route a PROPFIND request against the old webdav endpoints like `/dav/files/username`, ocdav first has to build a CS3 namespace prefix, eg. `/users/{{.Id.OpaqueId}}` to the users home. {{}} %%{init: {"sequence": { "showSequenceNumbers":true, "messageFontFamily":"courier", "messageFontWeight":"normal", "messageFontSize":"11"}}}%% @@ -150,11 +150,11 @@ sequenceDiagram ocDAV->>+ocDAV: {namespace/prefix} = ApplyLayout({path layout}, User), eg. /users/e/einstein Note right of ocDAV: look up the space responsible for a path ocDAV->>+Gateway: ListStorageSpaces(path: {namespace/prefix}/{relative/path}) - Gateway-->>-ocDAV: []StorageSpace + Gateway-->>-ocDAV: []StorageSpace Note right of ocDAV: make actual request with space and relative path ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path}) - Gateway-->>-ocDAV: []ResourceInfo - ocDAV-->>-Client: 207 Multistatus + Gateway-->>-ocDAV: []ResourceInfo + ocDAV-->>-Client: 207 Multistatus end {{}} @@ -192,9 +192,9 @@ sequenceDiagram end Note right of ocDAV: look up the space responsible for a path ocDAV->>+Gateway: ListStorageSpaces(path: {namespace/prefix}/{relative/path}) - Gateway-->>-ocDAV: []StorageSpace + Gateway-->>-ocDAV: []StorageSpace Note right of ocDAV: make actual request with space and relative path ocDAV->>+Gateway: ListContainer({spaceid}, path: {relative/path}) - Gateway-->>-ocDAV: []ResourceInfo - ocDAV-->>-Client: 207 Multistatus + Gateway-->>-ocDAV: []ResourceInfo + ocDAV-->>-Client: 207 Multistatus {{}} diff --git a/docs/extensions/app-registry/apps.md b/docs/extensions/app-registry/apps.md index d35b2e82a2..f9c57e6821 100644 --- a/docs/extensions/app-registry/apps.md +++ b/docs/extensions/app-registry/apps.md @@ -282,7 +282,7 @@ HTTP status code: 200 ```json { "code": "RESOURCE_NOT_FOUND", - "message": "error: not found: app 'Collabor' not found" + "message": "error: not found: app 'Collabora' not found" } ``` diff --git a/docs/extensions/graph/groups.md b/docs/extensions/graph/groups.md index c32e1c9356..74b42c95d3 100644 --- a/docs/extensions/graph/groups.md +++ b/docs/extensions/graph/groups.md @@ -23,10 +23,10 @@ The JSON representation of a Group as handled by the Groups API looks like this: Our implementation currently supports two Attributes for a Group: -| Attribute | Description | -|---------------|-------------| -| displayName | The groups name| -| id | An unique, stable readonly identifier for the group that stays the same for the whole lifetime of the User, usually a UUID| +| Attribute | Description | +|---------------|-----------------------------------------------------------------------------------------------------------------------------| +| displayName | The groups name | +| id | An unique, stable readonly identifier for the group that stays the same for the whole lifetime of the Group, usually a UUID | ### Reading groups diff --git a/docs/extensions/graph/users.md b/docs/extensions/graph/users.md index fe4dadfeff..e14c403f6d 100644 --- a/docs/extensions/graph/users.md +++ b/docs/extensions/graph/users.md @@ -25,13 +25,13 @@ The JSON representation of a User handled by the Users API looks like this: Our implementation currently supports only a limited set of Attributes of Users: -| Attribute | Description | -|---------------|-------------| -| displayName | The full name of the user, usually a combination for givenname and lastname| -| mail | The user's email address | -| onPremisesSamAccountName | The loginname/account name of the user| -| id | An unique, stable readonly identifier for the user that stays the same for the whole lifetime of the User, usually a UUID| -| passwordProfile | Contains the password of the users. This is only present when updating or creating users. It is never returned by the API| +| Attribute | Description | +|---------------|---------------------------------------------------------------------------------------------------------------------------| +| displayName | The full name of the user, usually a combination of given name and last name | +| mail | The user's email address | +| onPremisesSamAccountName | The loginname/account name of the user | +| id | An unique, stable readonly identifier for the user that stays the same for the whole lifetime of the User, usually a UUID | +| passwordProfile | Contains the password of the users. This is only present when updating or creating users. It is never returned by the API | ### Reading users diff --git a/docs/extensions/storage/terminology.md b/docs/extensions/storage/terminology.md index 638fb25c7c..e8a98d9684 100644 --- a/docs/extensions/storage/terminology.md +++ b/docs/extensions/storage/terminology.md @@ -83,7 +83,7 @@ a *quota* and *permissions*, identified by a `storage space id`. {{< figure src="/extensions/storage/static/storagespace.drawio.svg" >}} -Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like anti virus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ... +Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like antivirus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A [*storage space registry*]({{< ref "#storage-space-registries" >}}) then allows listing the capabilities of [*storage spaces*]({{< ref "#storage-spaces" >}}), e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ... Finally, a logical `storage space id` is not tied to a specific [*storage provider*]({{< ref "#storage-providers" >}}). If the [*storage driver*]({{< ref "#storage-drivers" >}}) supports it, we can import existing files including their `file id`, which makes it possible to move [*storage spaces*]({{< ref "#storage-spaces" >}}) between [*storage providers*]({{< ref "#storage-providers" >}}) to implement storage classes, e.g. with or without archival, workflows, on SSDs or HDDs. diff --git a/docs/ocis/deployment/bridge.md b/docs/ocis/deployment/bridge.md index 80a665a6f0..44f8c44522 100644 --- a/docs/ocis/deployment/bridge.md +++ b/docs/ocis/deployment/bridge.md @@ -15,7 +15,7 @@ This document is a work in progress of the current setup. ## Current status -Using ocis and the ownCloud 10 [graphapi app](https://github.com/owncloud/graphapi/) it is possible today to use an existing owncloud 10 instance as a userbackend and storage backend for ocis. +Using ocis and the ownCloud 10 [graphapi app](https://github.com/owncloud/graphapi/) it is possible today to use an existing owncloud 10 instance as a user backend and storage backend for ocis. ## How to do it @@ -117,7 +117,7 @@ $ ldapsearch -x -H ldap://127.0.0.1:9125 -b dc=ocis,dc=test -D "cn=admin,dc=ocis ``` {{< hint >}} -This is currently a readonly implementation and minimal to the usecase of authenticating users with an IDP. +This is currently a readonly implementation and minimal to the use-case of authenticating users with an IDP. {{< /hint >}} ### Start ocis storage-gateway, storage-authbasic and storage-userprovider diff --git a/docs/ocis/storage-backends/cephfs.md b/docs/ocis/storage-backends/cephfs.md index d46af51cc1..ed1e1133a3 100644 --- a/docs/ocis/storage-backends/cephfs.md +++ b/docs/ocis/storage-backends/cephfs.md @@ -17,7 +17,7 @@ The cephfs development happens in a [Reva branch](https://github.com/cs3org/reva ## Architecture -In the original approach the driver was based on the [localfs](https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go) driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create subvolumes for user homes and maintain a file id to path mapping using symlinks. +In the original approach the driver was based on the [localfs](https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go) driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create sub-volumes for user homes and maintain a file id to path mapping using symlinks. ## Implemented Aspects The recursive change time built ino cephfs is used to implement the etag propagation expected by the ownCloud clients. This allows oCIS to pick up changes that have been made by external tools, bypassing any oCIS APIs. @@ -45,7 +45,7 @@ Trash is not implemented, as cephfs has no native recycle bin and instead relies Shares [are mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#diff-5e532e61f99bffb5754263bc6ce75f84a30c6f507a58ba506b0b487a50eda1d9R168-R224) supported by cephfs. The share manager is used to persist the intent of a share and can be used to periodically verify or reset the ACLs on cephfs. ## Future work -- The spaces concept matches cephfs subvolumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup. +- The spaces concept matches cephfs sub-volumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup. - The share manager needs a persistence layer. - Currently we persist using a single json file. - As it basically provides two lists, *shared with me* and *shared with others*, we could persist them directly on cephfs!