[Concept Analysis] Allow access to file tree on higher level

[DeepDiver1975]

Background

The API as of today is designed to list files for the logged in user. The sdk does not allow access/listing of other resources like folders of other users or even other resources.

Solution

oc.files.list('') will return dav entries for remote.php/dav
oc.files.list('/files/foo') will return the files of the user foo
oc.files.list('/calendar/foo') will list calendars of the user foo (as example ...)

oc.files feels wrong then ..... ❓

[PVince81]

how about oc.files.list('path/to/folder', userId) then ? if no userId is specified (undefined) it would default to the currently logged in one.

did we implement trashbin yet ? I'd see it as oc.trashbin.list('path/to/subfolder', userId) then

[DeepDiver1975]

Well - the idea is to grant access to future existing file/folder resources - e.g. project folders. The path could be remote.php/dav/projects/mars-earth-communication-project/

This is a requirement taken from @labkode for Cern which has project rooms already implemented.

[PVince81]

In that case have a generic oc.dav.list(resourceType, userId, '...') maybe ? or just pass in the full string ?

then the specific implementations like oc.files.list(...) can rely on the above to do the call, and additionally do their own parsing / wrapping into objects which the oc.dav.list() does not (raw results)

[DeepDiver1975]

Another idea falling into this area: Using a config option is phoenix to use a different point on the folder structure as starting point - e.g. one of the project folders

In such a scenario we would need to use the same api to access any point in the structure.

oc.dav.* could be that one api - leaving oc.files.* basically unused ...

I was anyhow thinking if a more generic api would be more suitable .......

[PVince81]

the problem with a more generic API is that also the data structure will be generic.

for example when parsing a PROPFIND from files, the generic way would just leave all properties as is and would not parse them for you into a nice structure (like converting the letter permissions to an actual permission mask)

this would make the SDK more lightweight and move the burden of interpreting Webdav properties to the clients

back then when I wrote pyocclient my goal was to hide all such ugliness to give a better developer experience.

I guess we'll need to make a design decision there and what the SDK is about. Is it a generic Webdav client with some auth layer or is it an ownCloud specific client with convenience features ?

[DeepDiver1975]

In addition we need to take into considerations the api changes which come to the sdk as soon as we implement the CS3Apis .... expecting quite some changes here as well ....

[PVince81]

it almost sounds like a brand new project... maybe it would be a CS3 JS SDK of some sorts ?

[PVince81]

unless we can pre-generate the JS SDK from the protobuf definitions.

then comes back the question: do we need a convenience layer on top of this to make the results more beautiful/usable for API users ?

[DeepDiver1975]

The idea is that we use owncloud-sdk in phoenix and the sdk has drivers - one for webdav and one for cs3.

The cs3 driver will use generated protobuf/grpc code as published by the cs3 repos.

[PVince81]

in this case we need to think about what data structure we use on API level.
if we keep as is, we need converters for both Webdav and CS3.

unless we want to use a Webdav-generic way (for oc.dav) and return the data as is, then we'd only need a converter for CS3.

now wondering if we need to get rid of the DAV terms in the API.
when thinking of CS3 API, we might even get rid of Webdav path names (the ones up to the root) and hide these behind API parameters. In the latter case a path like "/$resourceId/$userId" would not be suitable on API level as this kind of path might not exist in the CS3 API.

[DeepDiver1975]

Sounds like we need a new issue to get this discussed .... I had some chats with @labkode regarding the dav properties. We shall document this as well .....

Let's see how the generated cs3api code looks like in js .... then we will see ....

[labkode]

Hi @DeepDiver1975 @PVince81, for storage related operations, oc.storageprovider.list('/a/path/to/anything') is enough. It gives the flexibility we need:

I replace oc.files for oc.storageprovider so we don't mix functionality with ownCloud apps:

• Access to user files: oc.storageprovider.list('/user/a/alice/')
• Access to project spaces: oc.storageprovider.list('/projects/d/doom/')
• Access to new spaces: oc.storageprovider.list('/magic/h/happens')
• Access to user files without global namespace: oc.storageprovider.list('/home/')

It is not the responsibility of the SDK to pass user information in the calls, the SDK will call WebDAV or GRPC with the given path and the user context, it is the responsibility of the storage provider to understand the user context and the given path.

As we discussed, the path to user files or project spaces should not be hard-coded in the code, Phoenix should provide a configuration to say:

• When a user clicks on All files tab the call goes to /user/a/alice or /home
• When a user click on All Projects tab the call goes to /projects/
• And applications can add new tabs pointing to new trees

This will avoid SDK changes any time a new name space is added.

For the webdav properties namespace and how to map them to grpc metadata keys, I had a chat with @slint, he is an expert on this subject working on digital repositories where name-spacing is crucial.

The keys for the GRPC metadata keys could be expanded schemas definitions,
for example:

• http://owncloud.org/ns/fileid
• http://owncloud.org/ns/favourite

This way we can use any namespace out there: dublin core, xml namespaces as far as we use them as a key for the metadata operations.

However, for common keys like a fileid, the namespace would be different and not specific to ownCloud, still to understand if there are some schemas out there for this field, but let's imagine something like this:

• http://cs3apis.org/schema/fileid

[PVince81]

Idea: provide APIs in the SDK for both high level and low level.

High level is "upload a file" and not having to care about chunking, etc.

Low level is "PUT something to a given endpoint" where the API user needs to be aware what the endpoint is called and how to chunk there for uploads.

The high level JS class could then internally use the low level JS class.

I suspect that with GRPC we'll only get the low level one, so we can nicely wrap it in the high level one as well.

[PVince81]

Would be nice to be able to grab a files API object or generic API object on any piece of the subtree: the use case I identified is that in Phoenix I don't want to have special handling when dealing with regular files and public links. I just want to initialize the client in one place and then pass that object to the file list view / mixin. The file list view should be able to perform any file operations without having to think about passing in token and password.
Ref: owncloud/web#2408

[DeepDiver1975]

superseded by the plan to use the graph api