On Wed, 2012-10-31 at 10:23 +0100, Guillaume Desmottes wrote:
Le mardi 30 octobre 2012 à 16:51 +0000, Philip Withnall a écrit :Another reason they’re used for storing linking data is that adding the linking data generally improves the quality of the user’s address book. For example, linking a Jabber contact to an EDS contact should result in the JID being added to the EDS contact’s list of JIDs. (I haven’t tested this recently, but that’s what the code’s meant to do.) This is unobtrusive and doesn’t mess up other EDS clients.This also introduces some weird side effects. If I have Alice on GTalk and Facebook but not in my EDS abook, she won't appear by default in gnome-contacts. But as soon as I merge those 2 personas she will because of this implementation detail. This is not the intended behaviour according to Allan ( https://bugzilla.gnome.org/show_bug.cgi?id=676411#c12 ).
Oh, good. I was under the impression it was a design decision (which I couldn't wrap my head around). I understand that some applications only care about one type of Persona within an Individual, but I think it's critical that one actual person is always presented the same way to the user (for consistency). I should make this a personal goal, because I don't think we're actually doing this right now.
Massive warning: the individual aggregator code is horrible, and has many irritating corner cases — but it works well at the moment (albeit slowly). If you want to rearchitect folks and make it all wonderful, I would strongly suggest you write a thorough set of unit tests for the aggregator first, or we *will* end up with regressions. Folks has a reputation for being unstable which I really don’t want perpetuated.Amen to that.
Agreed on all counts. Those tests should be added anyhow, but I would vote against any significant changes to the aggregator that doesn't make the aggregator tests exhaustive (and still pass them). -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature