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

[Rob Bradford <rob robster org uk>]

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.

Cheerio,

Rob