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 _______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers