Is there any way to make thumbnails work?

[deliciouslytyped]

Could you implement / is there some way to make (performant) thumbnails / previews work with the WebDAV mount?

I've done a *very small amount of research and apparently WebDAV doesn't have any standard for this so it would have to be handled on the client/server. I'm not sure - maybe this wouldn't even be DAVx5's responsibility at all, but then is there an open source client that would be open to implementing something custom?

• Found this: https://stackoverflow.com/questions/26284493/webdav-specification-thumbnail-preview-file-image

[rfc2822]

You can find the current DAVx5 thumbsnails code here:

https://github.com/bitfireAT/davx5-ose/blob/main-ose/app/src/main/kotlin/at/bitfire/davdroid/webdav/DavDocumentsProvider.kt#L551-L619

It generates thumbnails when

• the network is not metered (= basically on WiFi),
• the calling client supports cancellation (→ no Material Files)

by just downloading the files, generating a thumbnail and putting it into a cache. So on WiFi with the correct client thumbnails work, but they're of course slow because every image has to be downloaded completely.

Implementing https://specifications.freedesktop.org/thumbnail-spec/latest/ is a very interesting idea. Do you know servers which support this? Or otherwise you could also generate the thumbnails manually then, but who should do so?

[deliciouslytyped]

I know nothing about this, but I at least wanted to get the idea up somewhere! :) Your interest is delightfully noted.

I'm just playing with a simple (?) WebDAV server ( https://github.com/mnutt/davros/ , https://apps.sandstorm.io/app/8aspz4sfjnp8u89000mh2v1xrdyx97ytn8hq71mdzv4p4d8n0n3h ) built for sandstorm.io (https://sandstorm.io https://github.com/sandstorm-io/sandstorm) to try to use for sharing some files.

Warning low SNR wall of text:

Oh, interesting. https://developer.android.com/guide/topics/providers/create-document-provider : Your document provider can also provide thumbnails for a document by overriding the DocumentsProvider.openDocumentThumbnail() method and adding the FLAG_SUPPORTS_THUMBNAIL flag to the supported files.

That means file managers, as long as they support SAF (which is the baseline here), don't need to implement the thumbnail handling themselves, davx5 can do the important part! (?) That makes this sound in reach.

Assuming that the XDG specification specifies whatever this .thumbnails directory is that I find on my computers sometimes, this approach looks thumbnail-per-file based and so you don't even necessarily need to modify the server or the client.

Regarding who should generate thumbnails I assume you mean whether the server, or the uploader, or davx5 should do it?

Well, I don't know. From an efficiency perspective, the uploader could upload a thumbnail when they do an upload, because it's convenient, but that seems like the only situation where that should happen. davx5 could add a thumbnail for a file that doesn't have one yet and it's downloading anyway. I don't thing anything else makes sense? When bandwidth is free, or you can force it to generate them. Otherwise the server should be generating thumbnails, but as a non-native (i.e. not implemented yet on any given WebDAV server) solution, that could probably be scripted. (- but it really seems like the server should be generating everything? at least most of the time?)

For example if there is a suitable way to connect to the WebDAV server or filesystem - say, a script can be used on the server, on the relevant filesystem (at least initially, IDK about WebDAV shenanigans) to generate previews independent of both the server and the file manager. (I guess it would still need to know when a file is in an idle state, so probably some kind of WebDAV locking - so it would probably be easiest to use WebDAV regardless.)

I don't know if the specification provides for this, but presumably a .thumbnails folder or thumbnail source one way or another would need to be exposed for every directory tree root used over WebDAV.

Edit: Maybe it would be important to check how any non-android file managers handle this for shared filesystems, given that the beginning of the spec explicity states the thumbnail store is central in some xdg directory. - buuut it looks like https://specifications.freedesktop.org/thumbnail-spec/latest/shared.html is also specified! There are some odd looking things in here though (without having read the rest of the spec...) As of 2021 this looks like a very obscure feature https://unix.stackexchange.com/questions/679065/how-to-use-the-shared-thumbnail-repository .

Two other random thoughts:

• If original images happen to support something like https://en.wikipedia.org/wiki/Interlacing_(bitmaps), maybe you can abort the download part way through once you've got enough , but I know nothing about this and it's too niche and sounds wasteful. (And depending on connection speed or whatever, maybe a bunch of data is already half way across the network by the time you cancel it?)
• From my extremely superficial skim of the links I pasted it seemed like owncloud/nextcloud implements something. (Their own extra API?) I don't know if any servers do the xdg thing. I thought a protocol extension might be important, but this is certainly simpler. If there was a central specification it could get more widely adopted. I didn't look into what the microsoft WebDAV spec extensions do but I wonder if they actually implement something for thumbnails.

[deliciouslytyped]

It turns out the file manager I was using is probably some variant of this https://www.apkmirror.com/apk/huawei/downloads-18/downloads-18-9-release/files-9-16-android-apk-download/ ,

• and I guess that doesn't have thumbnails? Some googling ( https://old.reddit.com/r/GalaxyTab/comments/1ajit2l/need_good_filenmanager_that_shows_thumbnails/ ) pointed to Fossify File Manager supporting thumbnails ( https://github.com/FossifyOrg/File-Manager ) .....buuut it looks like that doesn't support the SAF stuff :/ Remote Support (like WebDAV) FossifyOrg/File-Manager#50
  (oh and I didn't check the cancellation stuff)

Material Files seems to have it's own WebDAV client that seems to do the same thing you do? (Or at least there is a toggle called "read remote files for thumbnail"). I don't see how to access the davx5 filesystem from Material Files. Also my version doesn't seem to have custom certificates yet (though presumably system level certs should work? zhanghai/MaterialFiles#1205) ( zhanghai/MaterialFiles#1187 WebDAV custom certificate support #1187 ), which davx5 does handle.

Which is to say I haven't found a client that would work with the existing thumbnails feature yet...

[rfc2822]

1. For Nextcloud, I found File preview WebDAV API nextcloud/server#6176 but I couldn't find whether there is a WebDAV property like nc:thumbnailURL pointing to an image that we can download and use as thumbnail. But I don't think so. Can you maybe check whether this is available for Nextcloud and/or create an enhancement issue for that?
2. The other thing would be to implement the FreeDesktop Thumbnail Managing Standard, but I doubt there are many servers/applications which generate such thumbnails, especially on WebDAV shares. So while this would be cool, I think the use will be limited and at the end, the work may be done for nothing because nobody generates such thumbnails.
3. On Windows, there seems to be thumbs.db, also on network drives. We could try to get and use the thumbnails from this file, when present.
4. Maybe there are other (possibly Apple/Linux-specific) ways, too?

So because there are so many ways to support thumbnails, it would probably be necessary to have some sort of registratry where the different thumbnail providers can hook in. Then the different thumbnail providers (always read-only) could be implemented:

• Nextcloud Preview API (but I think it would have to be provided by Nextcloud publicly first, as it seems to be internally only)
• FreeDesktop thumbnails
• thumbs.db
• …

But still: Are these things used enough that it's worth the effect? I'd say the most effect to get the Nextcloud and maybe thumbs.db things to work.

[rfc2822]

See also #1314 – but I think it will take some time until we find time

[deliciouslytyped]

After some fiddling (PEBKAC), I got Material Files to work with the baseline file download solution. Though I guess that might be it's internal implementation for which I quoted the toggle setting above.