Re: [Evolution-hackers] custom labels

[Patrick Ohly <patrick ohly gmx de>]

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