shared wasabi implementation
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Mon Feb 19 15:02:01 PST 2007
2007/2/19, Max Wiehle <max.wiehle at gmail.com>:
> Am Montag, den 19.02.2007, 23:14 +0100 schrieb Mikkel Kamstrup
> > 2007/2/19, Max Wiehle <max.wiehle at gmail.com>:
> > Hi,
> > Hope it's okay if i just jump right into the discussion. I
> > just read
> > about wasabi on a dashboard-hackers and i am quite interested
> > in it so i
> > tried to catch up with the mailing list archive. I worked on a
> > metadata
> > store for beagle during last years Summer of Code and i am
> > still trying
> > to follow what happens on the desktop search / metadata side
> > of things
> > as time permits.
> > Am Sonntag, den 18.02.2007, 21:15 +0100 schrieb Mikkel
> > Kamstrup
> > Erlandsen:
> > >
> > > Ok. If we are to standardize something like this, I would
> > assume that
> > > we use dbus for rpc - as far as I can tell that doesn't seem
> > to be a
> > > problem..? Fx a dbus api like:
> > >
> > > - AddFile (in as metadata, in s input_file)
> > > - AddText (in as metadata, in s text)
> > >
> > > where the metadata argument contains things such as uri,
> > mime, and hit
> > > type (in some specified order (and maybe some
> > > filtering/stemming/whatnot info)). The AddFile method sorta
> > replaces
> > > the "drop-in-special-dir" approach - the drop-in-special-dir
> > method
> > > could still be allowed for apps not talking dbus. The
> > AddText method
> > > should encapsulate the functionality of Beagles' current
> > > IndexServiceRequest/Indexable duo.
> > Maybe it would be possible to have a
> > - AddMetadata (in as metadata, in s uri)
> > as well. This could be used for all kinds of metadata that is
> > added to a
> > object aside from indexing. fx tags, emblems, notes in
> > nautilus. Or
> > epiphany might add "downloaded_from" to a files metadata -
> > saved
> > attachements could be marked as belonging to a certain email
> > and vice
> > versa etc.
> > Agreed. I figure this belongs under the Wasabi metadata spec and api -
> > which is yet to be discussed. Maybe I better kick that off soonish -
> > the search spec relies on some bits and pieces from it anyway.
> > The two methods I mention is specifically only targeting an indexer
> > since I don't think it should be a requirement to both an indexer and
> > metadata storage.
> Okay, i did not know there was a seperate metadata spec and api. Makes
> > Is there any where we can have a look at your work?
> Its in the beagle svn in
> mostly in beagled/SqliteMetadata/...
> It's only the store and some internal beagle changes that save metadata
> to the store. But there is no external api yet.
> EntityStore.cs is the central store.
> SqlMetaTests/TestEntityStoreBasics.cs illustrates the usage a little
> SqlMetadata.cs implements an EntityStore that tries to verify metadata
> against a model supplied in SqlMetaModel and stores it marked as
> non_verified anyway if it can't be verified.
> If there are any questions please ask. I am quite busy right now but i
> will be working on similar things from april on for my diploma thesis so
> i will try and keep in touch.
Cool, I will have a look at it when I can find some time...
Just a quick question: Do you do hierarchical metadata - in the sense that
fx Type:Music is a subtype of Type:Audio so that searching in the Type:Audio
field also turns up stuff with Type:Music?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg