shared wasabi implementation

[Mikkel Kamstrup Erlandsen]

2007/2/19, Max Wiehle <max.wiehle at gmail.com>:
>
> Hi,
>
> Am Montag, den 19.02.2007, 23:14 +0100 schrieb Mikkel Kamstrup
> Erlandsen:
> > 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
> sense.
>
> > Is there any where we can have a look at your work?
> Its in the beagle svn in
> http://svn.gnome.org/viewcvs/beagle/branches/beagle-metadata-branch/
> 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
> bit.
> 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?


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070220/a6a38d91/attachment.htm