6:08 a.m.
Hello!
According to its CtCap, Memotoo supports the X-EVOLUTION-FILE-AS
extension:
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
But it seems to get lost, which breaks the testExtensions test.
This is provided by Evolution:
BEGIN:VCARD
VERSION:3.0
NICKNAME:user15
NOTE:Spouse's Name: foobar
FN:spouse name
N:name;spouse;;;
X-EVOLUTION-FILE-AS:spouse\, name
UID:pas-id-4E4C7EDE00000180
REV:2011-08-18T02:54:22Z
END:VCARD
This is sent to Memotoo as:
BEGIN:VCARD
VERSION:2.1
REV:20110818T025422Z
N:name;spouse;;;
FN:spouse name
X-EVOLUTION-FILE-AS:spouse, name
X-GENDER:
NICKNAME:user15
TITLE:
ORG:;;;
ROLE:
TEL:
EMAIL:
URL:
X-MOZILLA-HTML:
ADR:;;;;;;
BDAY:
NOTE:Spouse's Name: foobar
PHOTO:
END:VCARD
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
Note that the comma was not considered special by the Synthesis encoder.
My memory is a bit fuzzy: is escaping it optional in vCard 3.0 optional
and/or does this depend on whether the property is meant to be a
comma-separated list? Lukas?
What comes back has an no X-EVOLUTION-FILE-AS:
BEGIN:VCARD
VERSION:3.0
REV:20110818T025434Z
N:name;spouse;;;
FN:name spouse
NICKNAME:user15
NOTE:Spouse's Name: foobar
END:VCARD
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
Thomas, Memotoo either has to preserve the property or must not declare
support for it in the CtCap.
--
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.
9:10 a.m.
Hello Patrick
Ok X-EVOLUTION-FILE-AS now works. Sorry to have forget to implement...
Thoma
Le 18/08/2011 12:08, Patrick Ohly a écrit :
Hello!
According to its CtCap, Memotoo supports the X-EVOLUTION-FILE-AS
extension:
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
But it seems to get lost, which breaks the testExtensions test.
This is provided by Evolution:
BEGIN:VCARD
VERSION:3.0
NICKNAME:user15
NOTE:Spouse's Name: foobar
FN:spouse name
N:name;spouse;;;
X-EVOLUTION-FILE-AS:spouse\, name
UID:pas-id-4E4C7EDE00000180
REV:2011-08-18T02:54:22Z
END:VCARD
This is sent to Memotoo as:
BEGIN:VCARD
VERSION:2.1
REV:20110818T025422Z
N:name;spouse;;;
FN:spouse name
X-EVOLUTION-FILE-AS:spouse, name
X-GENDER:
NICKNAME:user15
TITLE:
ORG:;;;
ROLE:
TEL:
EMAIL:
URL:
X-MOZILLA-HTML:
ADR:;;;;;;
BDAY:
NOTE:Spouse's Name: foobar
PHOTO:
END:VCARD
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
Note that the comma was not considered special by the Synthesis encoder.
My memory is a bit fuzzy: is escaping it optional in vCard 3.0 optional
and/or does this depend on whether the property is meant to be a
comma-separated list? Lukas?
What comes back has an no X-EVOLUTION-FILE-AS:
BEGIN:VCARD
VERSION:3.0
REV:20110818T025434Z
N:name;spouse;;;
FN:name spouse
NICKNAME:user15
NOTE:Spouse's Name: foobar
END:VCARD
http://syncev.meego.com/2011-08-17-18-20_synthesis_memotoo_mobical_google...
Thomas, Memotoo either has to preserve the property or must not declare
support for it in the CtCap.
11:12 a.m.
On Do, 2011-08-18 at 15:10 +0200, Thomas Pequet wrote:
Ok X-EVOLUTION-FILE-AS now works. Sorry to have forget to
implement...
Confirmed, works now. Thanks!
--
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.
12:18 p.m.
On Aug 18, 2011, at 12:08 , Patrick Ohly wrote:
This is provided by Evolution:
[...]
X-EVOLUTION-FILE-AS:spouse\, name
[...]
This is sent to Memotoo as:
X-EVOLUTION-FILE-AS:spouse, name
[...]
Note that the comma was not considered special by the Synthesis encoder.
My memory is a bit fuzzy: is escaping it optional in vCard 3.0 optional
and/or does this depend on whether the property is meant to be a
comma-separated list? Lukas?
For vCard 2.1, the engine only escapes when the contents is really a comma separated
list.
For vCard 3.0, commas are always escaped.
That is, when actually generating that property normally. It seems however that
X-EVOLUTION-FILE-AS was created using the "unprocessed" mode (X-*), which does
not do any deescaping or escaping (except for lineends). So if X-EVOLUTION-FILE-AS did not
have the escape on input, it would not be reproduced with comma escapes on output.
At least it was meant to work like this, and it also does when generating X-* properties.
However when looking at the code I found that the code checking the *de*-escaping has a
bug and IMHO would have converted a sequence like "foo\,bar" into
"foo,,bar", i.e. duplicated the escaped char instead of retaining the escape. I
wonder why that double comma is not seen in the version from Evolution (after being parsed
into a syncitem, of course).
Anyway, here's a patch which fixes the deescaping bug, even if that seems not directly
related to the issue.
Still, I'd like to understand what exactly happened here. Any ideas?
Best Regards,
Lukas
From ffdaf33a39da012969d3292b885963d8bd533cae Mon Sep 17 00:00:00 2001
From: Lukas Zeller <luz(a)plan44.ch>
Date: Thu, 18 Aug 2011 18:12:31 +0200
Subject: [PATCH] engine: MIME-DIR, fixed de-escaping in
only-de-escape-linefeeds mode
The way the code was before, a sequence like "foo\,bar" would have
been converted into "foo,,bar", i.e. duplicated the escaped char
instead of retaining the escape.
---
sysync/mimedirprofile.cpp | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sysync/mimedirprofile.cpp b/sysync/mimedirprofile.cpp
index caaa262..985601e 100644
--- a/sysync/mimedirprofile.cpp
+++ b/sysync/mimedirprofile.cpp
@@ -3689,7 +3689,7 @@ bool TMimeDirProfileHandler::parseValue(
c=*p;
if (!c) break; // half escape sequence, ignore
else if (c=='n' || c=='N') c='\n';
- else if (aOnlyDeEscLF) val+=c; // if deescaping only for \n, transfer escape
char into output
+ else if (aOnlyDeEscLF) val+='\\'; // if deescaping only for \n,
transfer this non-LF escape into output
// other escaped chars are shown as themselves
}
// add char
--
1.7.5.4+GitX
3:12 p.m.
On Do, 2011-08-18 at 18:18 +0200, Lukas Zeller wrote:
> This is provided by Evolution:
> [...]
>
> X-EVOLUTION-FILE-AS:spouse\, name
>
> [...]
>
> This is sent to Memotoo as:
>
> X-EVOLUTION-FILE-AS:spouse, name
>
> [...]
>
> Note that the comma was not considered special by the Synthesis
encoder.
> My memory is a bit fuzzy: is escaping it optional in vCard 3.0
optional
> and/or does this depend on whether the property is meant to be a
> comma-separated list? Lukas?
For vCard 2.1, the engine only escapes when the contents is really a
comma separated list.
For vCard 3.0, commas are always escaped.
That explains it then. X-EVOLUTION-FILE-AS is defined as a normal
property in the SyncEvolution config:
<field name="FILE-AS" type="string"
compare="conflict"
merge="fillempty"/>
[...]
<property name="X-EVOLUTION-FILE-AS">
<value field="FILE-AS"/>
</property>
It gets sent as vCard 2.1 and thus the comma is not escaped.
Regarding comma handling in wildcard properties: I can reproduce that
the comma is getting duplicated. However, your patch doesn't help. I
need to look more closely before I can say why.
--
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.
9:20 a.m.
On Fr, 2011-08-19 at 21:12 +0200, Patrick Ohly wrote:
Regarding comma handling in wildcard properties: I can reproduce
that
the comma is getting duplicated. However, your patch doesn't help. I
need to look more closely before I can say why.
The patch works... but it is not yet deployed on the plan44 SyncML
server ;-)
What I was seeing in my tests was a duplication of the comma on the
server side. The client did everything correctly, as a test with Memotoo
showed.
--
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.
4:28 p.m.
Hi Patrick,
On 24.08.2011, at 15:20, Patrick Ohly wrote:
On Fr, 2011-08-19 at 21:12 +0200, Patrick Ohly wrote:
> Regarding comma handling in wildcard properties: I can reproduce that
> the comma is getting duplicated. However, your patch doesn't help. I
> need to look more closely before I can say why.
The patch works…
Thanks for confirming this!
but it is not yet deployed on the plan44 SyncML server ;-)
I know. The process to maintain the OS repo is currently a bit cumbersome, I'm about
to figure out something better, but it requires a lot of tiding up on my part so it'll
probably take a while until I'll be able to push patches more quickly rather than in
batches only.
I'm also considering moving the repo elsewhere, like github or gitorious (you
foreclosed the latter more or less, at least the description text on
http://syncevolution.org/development reads "gitorious" for the upstream repo
already :-)
Best Regards,
Lukas
3475
days inactive
3481
days old
syncevolution@synevolution.org
6 comments
3 participants
participants (3)
-
Lukas Zeller -
Patrick Ohly -
Thomas Pequet