On Wed, 2008-12-10 at 16:37 +, Michael Meeks wrote:
[CUT]
So there is at least some bound to the growth of the deleted UUID
log ;-) which is the size / likelyhood of re-use in the UUID space.
It's hard to think of solutions that are that satisfying; but - perhaps
something
On Wed, 2008-12-10 at 11:12 +, Michael Meeks wrote:
Hi Philip,
On Tue, 2008-12-09 at 19:59 +0100, Philip Van Hoof wrote:
http://live.gnome.org/Evolution/Metadata
For early visitors of that page, refresh because I have added/changed
quite a lot of it already.
Looks really
Hi Philip,
On Wed, 2008-12-10 at 12:49 +0100, Philip Van Hoof wrote:
What does the lifecycle for the data in that Unset store look like ?
I think the LifeCycle is best described by this document:
http://live.gnome.org/MetadataOnRemovableDevices
It specifies a metadata cache format
On Tue, 2008-12-09 at 18:00 +0530, Sankar wrote:
Hey Sankar,
I'm writing a plugin that will implement the Manager class as
described here. Tracker will then implement being a Registrar.
http://live.gnome.org/Evolution/Metadata
I will be using camel-db.h as you hinted me on IRC to implement the
On Tue, 2008-12-09 at 13:59 +0100, Philip Van Hoof wrote:
On Tue, 2008-12-09 at 18:00 +0530, Sankar wrote:
Hey Sankar,
I'm writing a plugin that will implement the Manager class as
described here. Tracker will then implement being a Registrar.
http://live.gnome.org/Evolution/Metadata
On Mon, 2008-12-08 at 18:59 +0100, Philip Van Hoof wrote:
All metadata engines are nowadays working on a method to let them get
their metadata fed by external applications.
Such APIs come down to storing RDF triples. A RDF triple comes down to a
URI, a property and a value.
For example (in
