Common spec/interface for file metadata

Jakub Stachowski qbast at go2.pl
Mon Sep 5 18:06:59 EEST 2005


Dnia poniedziałek, 5 września 2005 16:22, Jamie McCracken napisał:
> Benedikt Meurer wrote:
> > 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.
>
> shouldn't be that bad for btree based databases as they burst read the
> file's metadata anyhow. For retrieval of any metadata it can be
> asynchronous so it shouldn't slow anything down at all.
>
> But what metadata would you need when loading a directory? The only one
> I can think of is MimeType perhaps which is currently async in Nautilus.

Try 'information list' view in konqueror and go into directory full of photos 
or mp3 files.

>
> I figured that metadata as a whole would only be retrieved with a
> "properties" dialog  (as it is in the case of the current Nautilus) so
> theres no need to pull down all metadata for all files when reading in a
> directory.

Your assumption is not always correct (see above). 



More information about the xdg mailing list