You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A deployment consists of a storage registry, storage providers, an ocdav handler and a graph api endpoint.
The storage registry organizes the storage spaces in a namespace.
The /webav endpoint then uses that namespace to provide human readable access to resources, but names and paths can change.
The /dav/spaces endpoint allows direct access to a storage space, regardless of the mount point.
To allow clients to build a custom registry (namespace) we need a way to expose the mount points for storage spaces.
When listing drives they should return a mountpoint property that contains the path in the global namespace that is accessible at /webdav, eg.: /personal/einstein for einsteins home space.
In oc10 / would be the users home and shares would be mounted in arbitrary locations.
In ocis we would make that /personal/einstein
The admin can build a namespace by mounting spaces in the storage registry as he sees fit. This is only a recommendation, because clients can build a completely different namespace if they desire. That includes storage spaces from other instances / deployments.
The text was updated successfully, but these errors were encountered:
A deployment consists of a storage registry, storage providers, an ocdav handler and a graph api endpoint.
The storage registry organizes the storage spaces in a namespace.
The
/webav
endpoint then uses that namespace to provide human readable access to resources, but names and paths can change.The
/dav/spaces
endpoint allows direct access to a storage space, regardless of the mount point.To allow clients to build a custom registry (namespace) we need a way to expose the mount points for storage spaces.
When listing drives they should return a
mountpoint
property that contains the path in the global namespace that is accessible at/webdav
, eg.:/personal/einstein
for einsteins home space.In oc10
/
would be the users home and shares would be mounted in arbitrary locations.In ocis we would make that
/personal/einstein
The admin can build a namespace by mounting spaces in the storage registry as he sees fit. This is only a recommendation, because clients can build a completely different namespace if they desire. That includes storage spaces from other instances / deployments.
The text was updated successfully, but these errors were encountered: