DVFS and Metadata

[Timo Stuelten]

On Sun, 6 Mar 2005, Jamie McCracken wrote:

> > What if the MQT changes from simple flat index to a
> > structure-semantic-someotherfunkymechanism index? To get a thumbnail for
> > a folder, there is no need for an enhanced metadata-DB. To get all thumbs
> > and compose all with transparency there maybe is. But then you may want
> > something more powerful than "thumb.1=aaa.png", "thumb.2=bbb.png" as
> > key-value-pairs for the folder.
> > And if you have this MQT, how to query it? Via getMetadata(folder:="abc",
> > key:="thumb.*") from the VFS-API?
> 
> I would imagine DVFS would have a getmetadata thing that returns a blob of
> key/value pairs or xml
Fine -- and now which of both? Flat key-value-pairs? XML with structure? 
key-value-pairs with possible references to other keys and this way with 
some structure too?

> The metadata will specify whats available (if it has thumbnails etc)
So do I get metadata about the metadata I could get? But how do I 
get the thumbnails then? Is it some key "hasThumbs", set to "true" telling 
me, there are thumbnails? Is there some RDF Statement in an XML fragment, 
saying <"file://.../a", "fdo:hasThumbs", "true">? And what do I have to 
query then?

I think the question is not how many daemons, threads, files or DBs should 
be used, but *what* to store/return. getMetadata("somekey") for flat 
key-value-pairs is fine -- a simple to use and probably simple to implement mechanism. 
Other techniques need some more possibilities to query metadata and 
another API I guess. But maybe I'm wrong -- I'm neither working on DVFS 
nor DConf, I only want to use it :) 

-Timo-

-- 
------------------------------------------------------------------------
Timo Stuelten
mailto: t.stuelten at tu-bs.de