Add Spaces to Capabilities

[refs]

In order for clients to be aware of the new spaces feature we need to enable the spaces flag on the capabilities' endpoint. As we currently do, the capabilities endpoints remains a hardcoded set of capabilities, and it will default to true.

diff --git a/go.mod b/go.mod
index f96e0f108..1fe1f0cca 100644
--- a/go.mod
+++ b/go.mod
@@ -79,6 +79,7 @@ require (
 )
 
 replace (
+	github.com/cs3org/reva => ../../refs/reva
 	github.com/crewjam/saml => github.com/crewjam/saml v0.4.5
 	go.etcd.io/etcd/api/v3 => go.etcd.io/etcd/api/v3 v3.0.0-20210204162551-dae29bb719dd
 	go.etcd.io/etcd/pkg/v3 => go.etcd.io/etcd/pkg/v3 v3.0.0-20210204162551-dae29bb719dd
diff --git a/storage/pkg/command/frontend.go b/storage/pkg/command/frontend.go
index ef686698b..aaf109f98 100644
--- a/storage/pkg/command/frontend.go
+++ b/storage/pkg/command/frontend.go
@@ -209,6 +209,10 @@ func frontendConfigFromStruct(c *cli.Context, cfg *config.Config, filesCfg map[s
 							},
 							"files": filesCfg,
 							"dav":   map[string]interface{}{},
+							"spaces": map[string]interface{}{
+								"enabled": true,
+								"version": "v0.1.0-beta",
+							},
 							"files_sharing": map[string]interface{}{
 								"api_enabled":                       true,
 								"resharing":                         true,

[C0rby]

Although this boolean flag is enough to fulfill the ticket, wouldn't it be nice to have some more information in the capabilities like which spaces API version the instance supports or something like that? I'm thinking about the long term here.

[refs]

Although this boolean flag is enough to fulfill the ticket, wouldn't it be nice to have some more information in the capabilities like which spaces API version the instance supports or something like that? I'm thinking about the long term here.

I think spaces should not have its own version, otherwise we would need to version WebDAV and OCS. The structure already contains a version of owncloud (or, oCIS):

// Version holds version information
type Version struct {
	Major   int    `json:"major" xml:"major"`
	Minor   int    `json:"minor" xml:"minor"`
	Micro   int    `json:"micro" xml:"micro"` // = patch level
	String  string `json:"string" xml:"string"`
	Edition string `json:"edition" xml:"edition"`
}

And IMO clients should act on this version.

While it makes sense to look to the future regarding APIs, the fact that ownCloud implement several APIs, we either version the product or version each API individually; the latter offers more granularity but it is more cumbersome.

If I think a bit further to the release cycle to the spaces API, changes would only be to the routes, since it is essentially just another WebDAV endpoint that allows for sharding, so even if semantics are different, the "way of doing things" is the same, and response types don't change, since they are webdav. Which brings us back to release cycles only adding more endpoints, not really changing functionality, and that can be tracked in the product, since we are not releasing new features (new endpoints being a new feature) without changing the version number (or at least we shouldn't).

This was my reasoning on only adding a boolean under the DAV type.

/cc @C0rby @labkode @dragotin

[refs]

@labkode this should be ready for review + merge

[refs]

@labkode 👍 removed the hardcoded condition, instead let the default config parsing handle it. From the config standpoint if looks something like this:

diff --git a/go.mod b/go.mod
index e7e6f4112..2f44e599c 100644
--- a/go.mod
+++ b/go.mod
@@ -76,6 +76,7 @@ require (
 
 replace (
 	github.com/crewjam/saml => github.com/crewjam/saml v0.4.5
+	github.com/cs3org/reva => ../../refs/reva
 	go.etcd.io/etcd/api/v3 => go.etcd.io/etcd/api/v3 v3.0.0-20210204162551-dae29bb719dd
 	go.etcd.io/etcd/pkg/v3 => go.etcd.io/etcd/pkg/v3 v3.0.0-20210204162551-dae29bb719dd
 )
diff --git a/storage/pkg/command/frontend.go b/storage/pkg/command/frontend.go
index ef686698b..9d623c625 100644
--- a/storage/pkg/command/frontend.go
+++ b/storage/pkg/command/frontend.go
@@ -208,7 +208,9 @@ func frontendConfigFromStruct(c *cli.Context, cfg *config.Config, filesCfg map[s
 								"preferred_upload_type": cfg.Reva.ChecksumPreferredUploadType,
 							},
 							"files": filesCfg,
-							"dav":   map[string]interface{}{},
+							"dav": map[string]interface{}{
+								"spaces": true,
+							},
 							"files_sharing": map[string]interface{}{
 								"api_enabled":                       true,
 								"resharing":                         true,

Tested the logic with this diff on oCIS and works as intended 👍

[micbar]

IMO spaces are not only a WebDAV thing.

If you ask me, we should introduce a new top-level entry for spaces.

[refs]

IMO spaces are not only a WebDAV thing.

If you ask me, we should introduce a new top-level entry for spaces.

@micbar brought the idea of introducing a new key for spaces

type Capabilities struct {
	Core          *CapabilitiesCore          `json:"core" xml:"core"`
	Checksums     *CapabilitiesChecksums     `json:"checksums" xml:"checksums"`
	Files         *CapabilitiesFiles         `json:"files" xml:"files" mapstructure:"files"`
	Dav           *CapabilitiesDav           `json:"dav" xml:"dav"`
	FilesSharing  *CapabilitiesFilesSharing  `json:"files_sharing" xml:"files_sharing" mapstructure:"files_sharing"`
	Notifications *CapabilitiesNotifications `json:"notifications,omitempty" xml:"notifications,omitempty"`
	Spaces        *CapabilitiesSpaces        `json:"spaces,omitempty" xml:"spaces,omitempty"`
}

type CapabilitiesSpaces struct {
	Enabled bool `json:"enabled" xml:"enabled"`
}

[refs]

@micbar ok, adding its own key is the way we're moving forward.

[refs]

@micbar + @labkode review please?

[micbar]

😄

[refs]

@labkode could you merge this one?