On Fri, 2014-04-11 at 12:18 +0200, Patrick Ohly wrote: > Hello! > > Both Google and Apple support custom labels for basically all of a > contacts properties (telephone, email, address, instant messaging, etc). > They use group tags to associate the extra label with the property: > > item4.ADR:;;custom address;;;; > item4.X-ABLabel:custom-label > > Does anyone have suggestions for how this could and/or should be handled > by EDS and Evolution? > > Obviously the Evolution UI would need to be modified to actually show > the information. As a first step I would already be happy if the > information didn't get lost during a import/edit/export cycle. > > I tried grouping, but when editing the field (an EMAIL in my test) its > group tag was removed, thus breaking the connection to the custom label. > After editing in Evolution: > > item1.X-ABLabel:foobar > EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified > > I also tried a custom parameter, but that also got lost: > > EMAIL;X-ABLabel=foobar;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:email value > -> > EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified > > I tried this with Evolution 3.4 (the one shipped with my current > desktop, Debian Stable). Has perhaps anything been done regarding this > in later versions? > > I am undecided about what EDS and Evolution should use internally to > represent custom labels. I lean towards a custom parameter because > although grouping is supported by EVCard, it hasn't been really used, > has it? The concept of "fields of interest" would still work if the > field also has the custom label as parameter (not that we have special > support for anything other than UID and REV, but at least conceptually > something else could also be supported).
The custom parameter has one major drawback: it cannot store arbitrary string values. Line breaks and double quotes are not possible. The EDS vCard parser is also slightly broken and fails for X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner A space without quoting is valid according to http://tools.ietf.org/html/rfc2425#page-5 but e-vcard.c complains "invalid character found in parameter spec" and proceeds at the next line. > On the other hand, deviating from the format of the peers will make > interoperability harder. I'm not sure yet how I would do the conversion > in SyncEvolution between X-ABLabel as parameter and X-ABLabel as > property with group. Importing/exporting vCards manually also is > affected by the choice of the internal format. Even if we used X-ABLabel + grouping, directly exchanging vCards with Apple will still not work properly due to the X-JABBER/AIM/... vs IMPP difference. Further work would be needed either way. I have not tested whether Apple understands X-AIM/JABBER/... instead of IMPP. I'm still undecided. A too complex X-ABLabel property value could be simplified to store it in a X-ABLabel parameter, but that'll drop user data. At this point it really would be good to get feedback from others. Is using groups going to be possible with EContact and Evolution or are we forced to use the simpler parameter approach, despite its limitations? Bye, Patrick _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
