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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xesam > -- Cheers, Kevin Kubasik http://kubasik.net/blog _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
