Re: [Evolution-hackers] Getting rid of shipped libdb

[Matthias Braun <matze braunis de>]

Am Dienstag, den 07.10.2008, 16:49 +0100 schrieb Rob Bradford:
> On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote:
> > On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote:
> > > Okay. Have you got these details? It would be good to see which of those
> > > still apply, etc..
> > 
> > 	Sure - the original rational here (AFAIR) is quite simple.
> > 
> > 	If you share the same .evolution across multiple machines, and the
> > version of libstupid is different: bad luck, you loose your contacts.
> 
> > 	Basically all database-y things seem to love back-compatibility ( if
> > you're lucky ), but the idea of forward compatibility seems to
> > completely bypass them; the concept that the functionality is good
> > enough already, and doesn't require further file-format breakage is
> > apparently not present ;->
> > 
> > 	AFAIR the addressbook usages of libdb for the local addressbook were
> > annoying enough in previous instances that we moved to having an
> > internal version.
> > 
> > 	What I'd love to see instead, is a one-shot migration to a simple plain
> > text, authoritative file with the contacts and then (perhaps) optionally
> > a binary cache I guess. But for the volume of data there, presumably
> > slurping it and grokking it with some small / simple piece of code would
> > be rather more efficient. Ultimately contact searches are in response to
> > user-input, so we have loads of time to do work there.
> 
> Hhh. But. The use case you outlined directly above about where this goes
> wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> that migrates it to Some Other Format (tm). You then add some contacts
> which go into the new format. Then you go back to your old machine.
> *Boing*. Same problem, your new contacts are missing :-(" 
> 
> Of course you can solve this by keeping the two backends around for as
> long you need (e.g. 1, 2, 3, 5, ..., n-1, n releases) OR you can dictate
> a policy saying that once you've migrated you can never go back.
> 
> I would expect migrating from one version of GNOME and then back again
> is probably pretty problematic anyway...ultimately I think you need to
> draw the line at some point.
> 
> (You can work around the forward/backward migration by for instance
> having full support in version n, but not migrate the user until (n+k).
> Then if the user goes back to >= n then then they can still access their
> old/new data.)
> 
> Somewhat orthogonally: Also, I wonder on the performance impact of the
> flat-file approach wrt, modification / deletion when dealing with ~1k
> contacts.

You should respect the lessons learned from mbox format vs. maildir for
mails. Simply use a single file per vcard and make the creation/deletion
performance an issue of the file system which usually deals with this
quiet well.

Greetings,
	Matthias