[Xesam] Metadata Storage Daemon

Kevin Kubasik kevin at kubasik.net
Wed Jan 16 01:21:18 PST 2008


OK, well the obvious agreement is a need for time/change tracking, I
added a dbus signal called on inserts and a method to get all new
triples since a specified timestamp. As for file monitoring, while a
Gnome-wide service would be nice, I think that it is outside the scope
of a metadata daemon (personally, open to more discussion on this).

I think that a rudimentary triple store (roughly like what I have
produced here) is a great _base_ for what we are all more or less
talking about. I think that the pushes for more searching/indexing
capabilities of the data here are missing the point, this is more a
simple storage engine. Powerful desktop search engines like Beagle and
Tracker can now both index the same stored metadata.

Anyways, I also added some more robust search/select style methods.
Please, its so easy to manipulate this API, I ask that if you have
feelings about something to do with this, and feel like people are
either
a) missing the point
or
b) misunderstanding you

just branch the code and provide us with a sample of what you are
trying to accomplish.

https://code.launchpad.net/gnome-metadata-store/+branches

Shows a list of current branches.

Cheers,
Kevin Kubasik

On Jan 15, 2008 8:26 PM, Evgeny Egorochkin <phreedom.stdin at gmail.com> wrote:
> В сообщении от Wednesday 16 January 2008 00:59:58 Jamie McCracken написал(а):
> > > > with a dumb metadata daemon you lose it (all the metadata still points
> > > > to the old file) unless something keeps it in check (which as i said
> > > > means changing vfs, email apps etc to do this)
> > >
> > > That is handled by another service. I don't think it is up to the indexer
> > > or the store to watch files (well, maybe the indexer to update data, ok,
> > > sure). And in the end even in your combined solution you have two
> > > components internally. So for the sake of decoupling and cleaner APIs we
> > > should define it as different services from the beginning.
> >
> > the user defined metadata store will be a separate dbus interface
> >
> > whether its a separate process is an implementation detail
>
> Doesn't make much sense to me. This separation(indexer-provided/user-provided
> and don't forget app-provided) metadata is better handled on the ontology
> level to provide flexibility. Of course storage can handle user metadata in a
> different way like make sure not to corrupt or lose it because unlike file
> index it can't be rebuilt.
>
> -- Evgeny
>
> _______________________________________________
> Xesam mailing list
> Xesam at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xesam
>



-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog


More information about the Xesam mailing list