Discuss freedesktop spec

[darkdragon-001]

See https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/83

[dragotin]

There does not seem to be too much drive in that discussion so far. We are very happy to discuss our solution which is in a good POC status meanwhile, as there does not seem to be another technical proposal. Btw, we also discussed openvfs with developers from Nextcloud.

I am a bit lost tough which is the best way to revitalize the discussion and get people involved. What do you suggest?

[Ebrathul]

@dragotin you mentioned there was not much drive in the freedesktop discussion
and that you were happy to talk about the openVFS approach — so while that is
quiet, I had a go at the desktop end of it and thought I would share what came
out.

It is a KOverlayIconPlugin that marks openVFS placeholder state in Dolphin and
other KIO file managers:

https://github.com/Ebrathul/openvfs-dolphin-overlay

It reads state from the extended attribute through libopenvfs, so there is no
sync client, no socket and no daemon involved, and it works for anything built
on openVFS rather than one particular client. Two states are shown, because
those are the two I could observe: online-only and stored locally.

A few things I ran into that might be worth knowing — I may well have misread
some of these, so please correct me where I have:

• A file manager asking again is not the same as it redrawing. Dolphin does
  re-query after a hydration, but keeps the overlay it already had until the
  plugin emits overlaysChanged. The queries it makes during a download all
  arrive before the state flips at the end, so the change has to be noticed
  another way.
• Watching the files is expensive. One 500 MB hydration produced about
  63,000 inotify events here. Re-reading the attribute for the few files that
  can still change, on a timer, turned out much cheaper.
• Is States::Hydrating meant to be set anywhere? I could only find it in
  the enum and in the two functions that turn it into a string. Polling the
  attribute every 50 ms across a 5.8 second download never caught an
  intermediate state, so downloads appear to go straight from dehydrated to
  hydrated. I kept an emblem for it in case that changes, but at the moment a
  file manager cannot show a download in progress. Is that deliberate, or just
  not wired up yet?
• Files with no placeholder attributes look hydrated. fromAttributes()
  answers hydrated for anything inside a mount whether or not an attribute is
  there, so a file the client has never registered is indistinguishable from a
  downloaded one. Reading etag/fileid does separate them, but only because the
  Nextcloud client fills those in — is that something libopenvfs would want to
  express directly?

The emblems are licensed LGPL-3.0-or-later OR CC-BY-SA-4.0 rather than GPL, on
purpose, so any client can ship them: no icon theme provides a cloud badge and
the obvious stand-ins are illegible at 16px, so it seemed worth making them
freely reusable.

If any of it looks useful in-tree, it is laid out to move as a directory rather
than a rewrite, and I am happy to adapt it to whatever shape suits you. Equally
happy for it to just live where it is.

[dragotin]

Interesting work, thanks. It looks to me like the way we intended to implement that, but haven't done that.

But I have to chew more on that.