Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Reference to the space in ResourceInfo #1804

Open
butonic opened this issue Jun 18, 2021 · 1 comment
Open

Add Reference to the space in ResourceInfo #1804

butonic opened this issue Jun 18, 2021 · 1 comment
Assignees

Comments

@butonic
Copy link
Contributor

butonic commented Jun 18, 2021

When trying to resolve URLs like https://cloud.ocis.test/f/<spacealias>/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607 the web may need to rely on the id if the <spacealias> is not unique or if a segment in the relative path was renamed.

The gateway will route requests to the correct storageprovider, the storageprovider can look up the resouce and return a ResourceInfo.

But currently the path is either

  • absolute in the global namespace (when an absolute reference was used) or
  • relative to the reference in the request -> always just the basename

What we do NOT get is the id of the space and where in the space the the resource is located. But that is what the web ui would need in the response to correctly show the space and the relative path to the resource with id b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607.

This was why I initially proposed using a Reference for the type of Path in the ResourceInfo.

I propose to add a new SpaceRef property of type Reference to ResourceInfo. When a relative Reference was used ResourceInfo can then contain the SpaceRef which might differ on who is accessing the resource: for the owner it would be the root of the personal space. For a share recipient it would be the root of the closest share when walking up the tree.

Why not return the complete relative path instead of the basename when a relative Reference was used in the request? The Reference:ResourceId may not have been a storage space root, but any node. The web UI would still not know which storage space to show.

An alternative would be to have a Parent Reference property in the ResourceInfo. Absolute path References would return a path, absolute id References would return the parent ResourceID. And relative references could return a Reference for the parent with the root of the Space as id and a relative path. Then it would however make sense to rename ResourceID:Path to Name because we split parent and name anyway.

I think a dedicated SpaceRef is semantically cleaner because it always points to the root of the closest space the current user has acces to with a relative path.

Related: owncloud/ocis#1876

cc @C0rby @pmaier1 @tbsbdr

@butonic
Copy link
Contributor Author

butonic commented Mar 23, 2022

An alternative would be to have a Parent Reference property in the ResourceInfo. Absolute path References would return a path, absolute id References would return the parent ResourceID. And relative references could return a Reference for the parent with the root of the Space as id and a relative path. Then it would however make sense to rename ResourceID:Path to Name because we split parent and name anyway.

This also makes sense for wopi which is trying to find out if it can access the parent of a resource.

Furthermore, GetPath() should return a path and a root resourceid for the relative path. The root might not always be a space root. It can also be any shared node.

A ParentID on the ResourceInfo should cover our needs in edge. A full Reference is not needed. To look up the full path the GetPath() is still needed.

cc @glpatcern @wkloucek @dragotin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants