Desktop Emblems Proposed Spec
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Thu Feb 1 23:02:12 EET 2007
2007/2/1, John Stowers <john.stowers at gmail.com>:
>
>
>
> > Another thing you don't seem to have covered. How would an application
> > determine what files have emblem X? Or how do an app set emblem X on a file
> > (or generally an uri)?
> >
> > This doesn't strictly have to be part of the proposal though...
> >
>
> Yeah I have intentionally left that out - in this case. I tried to
> elaborate a bit in the section on "Relationship to tags" to clarify this
> spec only covers the definition of emblems.
>
> While that might make this spec a bit simple I see it as a necessary first
> step. To be honest I was going to see how Wasapi pans out and then start to
> think about a common DBus API for associating metadata with files at a later
> date. Such an api could be
>
> AttachKeyword(keyword, uri)
> AttachEmblem(emblem, uri)
> etc
>
> I do believe that this spec would form a necessary basis for such an API
> (in the emblem case), or could at least be absorbed by that spec at a
> subsequent date
>
Yes, this could very well fall under the Wasabi umbrella, but as you say,
let's let that rest for now.
I think that standardising on the emblems first, and then an API for
> associating them with files is about as far as you can go for standardising
> tags/keywords/emblems and stuff. I believe it would be prohibitively
> restrictive, performance wise, to require indexers also keep a
> (hypothetical) xml file describing the association of all emblems to files,
> in addition to their own internal representations of such relationships [1]
>
You are right. An api like you suggest does not enforce a policy on how to
actually store the emblem information so any platform could do what it
found was the right thing.
[1] Perhaps the answer here is standardising on something like XMP sidecar
> files and having indexers periodically write these out to disk. In that case
> they would no doubt need to refer back to an emblem which may have been
> applied to the associated file.
>
As I understand it indexers (atleast Beagle and Tracker) have problems
"regarding two files as one", meaning that they will probably be able to
write the sidecar, but not index it so that the metadata is stored for the
original file.
Anyway, let's postpone the api discussions until the fileformat is set in
stone, and Wasabi is firing up on the metadata spec.
Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070201/985a8431/attachment.htm
More information about the xdg
mailing list