Provide DAV endpoint to directly access favorites

[PVince81]

It could look like: "remote.php/dav/favorite/$userId/".

• The folder "$userId" would contain every favorite file and folder.
• The user folder itself does not accept creating new entries
• Exploring inside subfolders works like regular DAV (could also be symlink or redirect to the actual DAV folder)
• Renaming entries would work
• Deleting entries would unfavorite them, or delete them completely ?

Now on the desktop client side or mobile, it might require a brand new UI. Unless we manage to build a virtual FS layer on top of the current one that could look like this:

• /
• /Home => contains regular home files as before
• /Favorites => contains favorites as represented by the above endpoint
• /Pending => contains received shares (if ever supported)
• ...

With selective sync the user can then choose to either sync regular home or favorites.

@michaelstingl @SamuAlfageme @DeepDiver1975 @butonic @pmaier1

[ownclouders]

GitMate.io thinks possibly related issues are #23269 (Consider new DAV endpoint for public shares), #25112 (webdav endpoints), #26064 (New DAV endpoint missing properties on files root), #12337 (Provide API endpoints for favorites/metadata/tags on files), and #28874 (Use new DAV endpoint in web UI).

[DeepDiver1975]

to get all favorited files we have the REPORT request defined. Why another collection here?

[PVince81]

Hmmm, but usual Webdav clients cannot mount REPORT requests. The advantage of this endpoint is that you can list its contents with PROPFIND.

With such endpoint you could access favorites with cadaver, dolphin, davfs, etc

[PVince81]

the same could be done for tags also

[DeepDiver1975]

I get our point .... let's try to find a more structured representation ... I have the feeling we are polluting the root collection .....

[PVince81]

I'm also a bit uncomfortable with the redundancy of ways to access the same information.

Agreed on avoiding root collection pollution.

[michaelstingl]

Now on the desktop client side or mobile, it might require a brand new UI.

No problem for iOS and Android. On the desktop, I'd like to test-drive the hybrid approach first. (open view in system browser with autologin)