Common spec/interface for file metadata

[Benedikt Meurer]

Jamie McCracken wrote:
>> While such an API is simple and works for some apps its certainly not
>> gonna be usable for applications like file managers or indexers. Calling
>> a separate out of process RPC for each file while loading a directory
>> would totally kill performance. 
> 
> If it were needed to be called on each file while loading a directory
> (which would only be for limited things like the mime type) then we
> could also have an API to return a specific metadata for each file in a
> directory in one shot.
> 
> EG
> 
> GetMimeTypesForFilesInFolder
>   input DBUS_TYPE_STRING s (the folder uri)
>   output DBUS_TYPE_DICT  a{ss} (the metadata as filename, mimetype)
> 
> Most of the other metadata would be retrieved on demand by users
> requesting to see additional metadata for a file so the previous API
> should suffice for that.

This would still be a performance problem for fast file managers, and it
would cause unnecessary load on the metadata implementation. Think of a
medium-size folder (around 1000 files). When the file manager enters the
directory it can display up to 50 files at once, and so it doesn't need
to know the metadata for the other 950 files until the user scrolls down
to the last file (slow scrolling in this case, so every file's view
item/row receives an expose event). Nevertheless, the "metadata daemon"
would need to fetch the data for all 1000 files and transfer them, even
tho the file manager needs only 5% of them.

What's required from a file managers POV is a fast way to lookup the
meta data available for a certain URI w/o much overhead (e.g. w/o any
RPCs). Perhaps an mmap()able file or an SQLite database. Or - for the
brave - store it in the extattrs of the file (tho this is probably not
the way to go as some file systems limit the size of the data stored
within the extended attributes of a file).

Benedikt