On Tue, 2014-04-29 at 18:00 +0200, Lukas Zeller wrote:
> Hi Patrick,
>
> you are faster in understanding the details than I could look them
> up :-)
Live and learn. Or use the source, Luke ;-)
However, it helps to spell out observations and thoughts occasionally,
so let me continue with a related problem.
I decided that a separate X-ABLabel for every TEL, ADR, X-ABDate,
X-ABRELATEDNAMES, etc. is too verbose and too different from
"traditional" usage of vCard. Recipients of such a vCard must be able to
understand and support groups, which is not guaranteed. For example, the
Evolution vCard parser supports groups, but the higher level of
abstraction does not (or not easily).
I also don't see what advantage X-ABLabel as property has over X-ABLabel
as parameter. I understand that a property could itself have parameters
or complex values, but that's not the case here. A simple string might
just as well be attached as parameter.
So that's what I am trying to do:
1. Parse with groups: X-ABLabel property enabled.
2. Throw away group tags.
3. Generate with parameter: X-ABLabel parameter enabled.
This direction works. What fails is reading such a generated vCard,
because different properties store their X-ABLabel parameter in the same
"LABEL" field array, overwriting each others' values.
The logic for choosing a position must now also (or instead?!) check
whether the LABEL position is unused when adding a new ADR. In other
words, when parsing an ADR, look at LABEL to determine the position. I
thought I could achieve that with:
<property name="X-ABLabel" suppressempty="yes" groupfield="GROUP_TAG"
rule="HAVE-ABLABEL-PROPERTY">
<value field="LABEL" repeat="array" increment="1" minshow="0"/>
<position field="LABEL" repeat="array" increment="1" minshow="1"/>
</property>
<property name="ADR" values="7" groupfield="GROUP_TAG">
<value index="0" field="ADR_POBOX"/>
<value index="1" field="ADR_ADDTL"/>
<value index="2" field="ADR_STREET"/>
<value index="3" field="ADR_CITY"/>
<value index="4" field="ADR_REG"/>
<value index="5" field="ADR_ZIP"/>
<value index="6" field="ADR_COUNTRY"/>
<position field="LABEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="ADR_STREET_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<!-- enum mode="prefix" name="X-CustomLabel-" value="1.L"/ -->
<!-- enum mode="prefix" name="X-Synthesis-Ref" value="2.L"/ -->
</value>
</parameter>
<parameter name="X-ABLabel" rule="HAVE-ABLABEL-PARAMETER">
<value field="LABEL"/>
</parameter>
</property>
However, when parsing a vCard with HAVE-ABLABEL-PARAMETER unset and
HAVE-ABLABEL-PROPERTY set,
sysync::TMimeDirProfileHandler::parseProperty() goes into an endless
loop involving sysync::TMultiFieldItem::adjustFidAndIndex() directly on
the first ADR:
ADR;TYPE=HOME:PO;neighborhood;home address\n;City;State;ZIP;Country
It's permanently increasing repoffset.
I've not looked further, but I suspect that this is because of using
LABEL twice, once indirectly via the group field and once via the
position field.
I'll try applying different <property> elements, even if that means more
duplication in the profile.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
