Hello Patrick, On 02.05.2014, at 10:38, Patrick Ohly <patrick.o...@intel.com> wrote:
>> What do you mean by "independent" properties?
>
> For example, ADR and TEL are independent in the sense that their values
> are stored in different field arrays. Sharing the LABEL field for the
> new parameter creates a dependency (or risk of collision) that did not
> exist before.
But how can this work at all? The index in the field arrays is what relates the
components (e.g. TEL, TEL_FLAGS and LABEL) to each other.
This would mean all of the field arrays would need to have rows for the *sum*
of all the TEL+ADR+EMAIL+URL+xxx, with most rows empty, to be able to share a
single LABEL array.
Now I see why you want to check the availability of LABEL row even if assigned
via a property parameter.
Hmmm - indeed this might work, at the expense of a lot of empty elements in the
actual property field arrays. I'm just not sure right now if the generator part
of MimeProfile is prepared for properly skipping entirely empty rows to avoid
generating empty property lines in the vCard output. But that would be fixable
as well.
> [...]
> It's simpler.
>
> TEL;X-ABLabel=labelTel:123456789
> ADR;X-ABLabel=labelAdr:xxx
>
> stores only the second label at position #0
> => LABEL = [ 'labelAdr' ]
Understood now. Yes, because the only thing TEL and ADR have in common is the
LABEL, and this is not checked.
> That's because the code which checks where to store the ADR value does
> not check whether the LABEL at the position is available.
>
> There's another problem:
>
> TEL:123456789
> ADR;X-ABLabel=labelAdr:xxx
>
> A simplistic check "LABEL[0] empty" will accept position #0 for ADR. But
> doing so will add the labelAdr also to the TEL, which was previously
> created at position #0.
>
> That means that the check has to be "LABEL[0] does not exist".
Yes. Fortunately, TItemField differentiates between empty and unassigned; the
check needs to be for the latter.
>>> Similar to "for (sInt16 e=0; e<aPropP->numValues; e++) {" the code would
>>> also need to iterate over aPropP->parameterDefs.
>>
>> Yes.
>
> This helped, but so far I have only implemented the too simplistic
> check.
>
> I noticed another problem with the "use X-ABLabel parameter" approach:
> storing complex strings (spaces, quotation marks) in a parameter value
> is harder.
That's probably why Apple chose the X-ABLabel property approach. An unparseable
parameter could ruin the real data, a unknown property is less dangerous.
> The EDS vCard parser gets it wrong and fails to parse:
>
> X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner
>
> That is valid according to http://tools.ietf.org/html/rfc2425#page-5
> because the space is a SAFE-CHAR and thus may appear in a ptext, but the
> EDS parser does not expect the space. To work around this, we could
> voluntarily quote the string even though it is not required.
>
> Now, the conceptual problem with "X-ABLabel parameter" is that a quoted
> string cannot contain double quotes. It is probably rare that a user
> enters double quotes as part of a label, but it cannot be ruled out
> either. Line breaks are also only allowed in property values and not
> parameter values.
>
> I'm undecided now how to proceed. Simplify X-ABLabel property values so
> that they can be stored as parameter? Use the more complex X-ABLabel
> property and grouping? Bummer.
Really hard to say :-(
I'd say it depends on how important these ABLabels are (outside of Apple
devices, that is. In iOS's Addressbook (AB), the Label IS important and
actually represents the standard TYPE of a TEL, EMAIL or ADR as well, by using
cryptic internal string constants like "_$!<Work>!$_" or "_$!<HomeFAX>!$_").
Best Regards,
Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
