Patrick Ohly | 7 Apr 14:45 2010
Picon

X-Synthesis-Ref and X-CustomLabel- TYPE extensions

Hello!

This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462

        Steps to reproduce:
        - sync Synthesis iPhone client, SyncEvolution server, Evolution
        - modify contact on iPhone
        - send to server and Evolution
        - TYPE="X-Synthesis-Ref0" is added to ADR, EMAIL, TEL

        Outcome:
        - Evolution shows email as "other" (might be right, there was no
        TYPE=HOME/WORK)
        - ADR is not shown (NOT right!)

        Our XML configuration contains the TYPE=X-Synthesis-x extensions. We inherited
        those from the Synthesis example config. Having them is useful when operating
        as server with the file backend, because the iPhone client can store and later
        retrieve its extensions.

        But when storing an item in Evolution, we should not add these extensions.

        Implementing that is tricky, because we don't want to maintain two different
        sets of vcard profiles. Not sure how to do this yet.

I have a few questions about this. First, X-Synthesis-Refx maps to the
field ADR_STREET_ID with value x. What is the semantic of this? Same for
ADR_STREET_LABEL, which would show up as X-CustomLabel-≤label>. I'm
asking to figure out whether this might be worth mapping to something in
Evolution or elsewhere.
(Continue reading)

Patrick Ohly | 15 Apr 15:05 2010
Picon

Re: X-Synthesis-Ref and X-CustomLabel- TYPE extensions

On Wed, 2010-04-07 at 13:45 +0100, Patrick Ohly wrote:
> Hello!
> 
> This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462
[...]
> I suppose for SyncEvolution 1.0 we should simply remove the extension
> from the XML config used by us. There's a slight loss of functionality
> when SyncEvolution is used as server for a Synthesis (iPhone) client,
> but that is not its primary role anyway.

I've implemented this. I'm still interested in hearing about how these
extensions should be handled by a server.

--

-- 
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.
Lukas Zeller | 19 Apr 16:26 2010
Picon

Re: X-Synthesis-Ref and X-CustomLabel- TYPE extensions

Hello Patrick,

time flies, and while I also spend some time organizing my new workplace, most of it gets still consumed by
Apple's new Gadgets and OSes (clearly one of the cash cows in our business, so that'd nothing I can neglect
too much). 

On Apr 7, 2010, at 14:45 , Patrick Ohly wrote:

> This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462
> 
>        Steps to reproduce:
>        - sync Synthesis iPhone client, SyncEvolution server, Evolution
>        - modify contact on iPhone
>        - send to server and Evolution
>        - TYPE="X-Synthesis-Ref0" is added to ADR, EMAIL, TEL
> 
>        Outcome:
>        - Evolution shows email as "other" (might be right, there was no
>        TYPE=HOME/WORK)
>        - ADR is not shown (NOT right!)
> 
>        Our XML configuration contains the TYPE=X-Synthesis-x extensions. We inherited
>        those from the Synthesis example config. Having them is useful when operating
>        as server with the file backend, because the iPhone client can store and later
>        retrieve its extensions.
> 
>        But when storing an item in Evolution, we should not add these extensions.
> 
>        Implementing that is tricky, because we don't want to maintain two different
>        sets of vcard profiles. Not sure how to do this yet.
(Continue reading)

Patrick Ohly | 19 Apr 16:56 2010
Picon

Re: X-Synthesis-Ref and X-CustomLabel- TYPE extensions

On Mon, 2010-04-19 at 15:26 +0100, Lukas Zeller wrote:
> On Apr 7, 2010, at 14:45 , Patrick Ohly wrote:
> 
> > This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462
> > 
> > Regarding solving this problem, the obvious choice would be to make
> > X-Synthesis-Ref depend on a specific rule: when encoding for Evolution,
> > don't enable the extension. But this is not possible at the moment.
> 
> Why not? Is the enhanced rule mechanism not sufficient yet for this? If not, what is missing?

I agree, we could duplicate the <property> definition, once with and
once without the extension. But these definitions tend to be large, so I
would rather like to enable specific <parameter> entries with a rule
parameter, which is not possible.

I logged some ideas how this could be improved via pre-processing here:
http://bugzilla.moblin.org/show_bug.cgi?id=10462#c1

--

-- 
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.
Patrick Ohly | 19 Apr 17:31 2010
Picon

UID in iCalendar 2.0

Hello!

I tracked down a problem caused by Evolution not being able to store two
iCalendar 2.0 items with the same UID. The root cause is that the server
doesn't know this, leading to
http://bugzilla.moblin.org/show_bug.cgi?id=9682

- clear all items on a server which uses the file backend
- slow sync with one item on client A
- modify item on client A so that a key element differs (like SUMMARY in task)
- slow sync again

Expected result:
- client and server in sync, either with one item or two

Actual result:
- server has two items, client one (the unmodified one from the initial sync)

The root cause is that the server treats these two items as different when
using the file backend, because neither that backend nor the engine know about
the significance of the UID property, which happens to be identical here.

In the second slow sync, it sends an <Add> command with the item that it had
from the initial sync. The client then turns the <Add> into a <Replace> of the
item that it just sent to the server, overwriting the local, more recent data
with the older copy from the server.

The client uses the EDS backend, which detects that the new item from the
server has the same UID as a local item, and therefore it *replaces* that item
instead of adding it anew.
(Continue reading)

Patrick Ohly | 21 Apr 09:39 2010
Picon

wrong interpretation of timezone information

Hello!

I have a meeting in my Evolution calendar which I synchronize with
SyncEvolution. I noticed that the outgoing VEVENT has start and end time
converted to UTC times which are one hour off.

Here's the stripped down event:

BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:GMT Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T010000
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:test event
DTSTART;TZID=GMT Standard Time:20100421T150000
(Continue reading)

Patrick Ohly | 26 Apr 14:40 2010
Picon

Re: wrong interpretation of timezone information

On Wed, 2010-04-21 at 09:39 +0200, Patrick Ohly wrote:
> I have a meeting in my Evolution calendar which I synchronize with
> SyncEvolution. I noticed that the outgoing VEVENT has start and end
> time
> converted to UTC times which are one hour off.
> 
> Here's the stripped down event:
> 
> BEGIN:VCALENDAR
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VTIMEZONE
> TZID:GMT Standard Time
> BEGIN:STANDARD
> DTSTART:16010101T020000
> TZOFFSETFROM:+0100
> TZOFFSETTO:+0000
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:16010101T010000
> TZOFFSETFROM:+0000
> TZOFFSETTO:+0100
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
> END:DAYLIGHT
> END:VTIMEZONE
> BEGIN:VEVENT
> SUMMARY:test event
> DTSTART;TZID=GMT Standard Time:20100421T150000
(Continue reading)

Lukas Zeller | 30 Apr 18:12 2010
Picon

Server progress events

Hello Patrick,

as promised I added server progress events now to the engine. See updates in "luz" branch (in particular
b15e49512c (engine 3.4.0.7: Progress events now session local and available for server sessions)).

It works exactly the same as in clients - SessionStep returns with stepCmd==STEPCMD_PROGRESS when there
is a progress event to show.

Best Regards,

Lukas Zeller (luz@...)
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
info@..., http://www.synthesis.ch

Gmane