Re: [Evolution-hackers] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
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 like cropping the deletion log-size at a percentage of stored mail size, with some log overflow type message to flag that; or having some arbitrary size bound on it, or more carefully disabling logging when search services are disabled, or ... having only a single client, or warning the user that they should run their search service some more, or perhaps even coupling the indexing piece more closely to the mailer itself somehow. After some discussion on IRC we decided to add a Cleanup method to the registrar's interface. This method will be called whenever Evolution has a reason to believe that the `last_checkout` date as passed during the registry of the registrar has become (or is) too old. After the Cleanup Evolution will do a re-import using mostly SetMany. I have updated http://live.gnome.org/Evolution/Metadata for this. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead
Hi Mikkel, On Sat, 2008-12-13 at 00:18 +0100, Mikkel Kamstrup Erlandsen wrote: Is it that big a problem? I mean if you store 100,000 uris of avg. length 50 chars you will have a file about 5mb... One needs only keep an absolute minimum amount of metadata around. Well, true - it's not that much data I suppose - but without an agreed lifecycle mechanism it grows without bound as you delete mail, and since we have to do a lookup prune for every new UUID we generate [ or arguably emit ], there are potential size performance issues prolly worth addressing (in some simple way) in the design. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
