headers
Patrick Ohly | 1 Feb 2010 17:12
Picon
Favicon
Gravatar

XML config fragments

Hello!

I've started splitting up the XML sample configs into individual files.
The first step just rearranges the content of the
src/sysync_SDK/configs. Patch in xml-config-fragments branch of
git.moblin.org libsynthesis repo - does that look okay so far?

I'll proceed to unify these configs with the ones we use in
SyncEvolution.

--

-- 
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.
Permalink | Reply | 8 comments |
headers
Lukas Zeller | 2 Feb 2010 10:18
Picon
Favicon
Gravatar

Re: XML config fragments

Hello Patrick,

On Feb 1, 2010, at 17:12 , Patrick Ohly wrote:

> I've started splitting up the XML sample configs into individual files.
> The first step just rearranges the content of the
> src/sysync_SDK/configs. Patch in xml-config-fragments branch of
> git.moblin.org libsynthesis repo - does that look okay so far?

Yes, thanks for the work of normalizing these!

One comment: Email sync is completely assymetric, so just copying the server side definitions will not
likely result in anything sensible (even if the scripts would execute in the client, which they won't
because they use server-only functionality).

I'd propose to move the email related definitions into the server folder.

I consider email sync a hack, and nowadays even POP3, let alone IMAP can do much much better. We added it 2003
because then some carrier customers were on a "single login" trip so they thought packing everything into
SyncML would be great. I never agreed to that but they paid for adding it nonetheless. To make it not looking
too bad compared with POP3, and not too slow, we had to add a number of non-standard extensions for only
sending a part of large emails and allow the user to pick which emails needed to be downloaded in full,
including attachments. The fun part in this was to figure out ways to add this without breaking the SyncML standard...
Only a few devices (P800,P9xx and the 9500 communicator and some descendants of that) still have email
sync, of course including our own WM and (with severely reduced features) PalmOS clients. For syncing
with these, the server side email support was left in the sample, but beyond I'd say email sync is obsolete.

Lukas Zeller (luz@...)
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lukas Zeller | 2 Feb 2010 12:23
Picon
Favicon
Gravatar

Re: detecting slow syncs

Hello Patrick,

On Jan 29, 2010, at 19:49 , Patrick Ohly wrote:

> Another peculiarity: on the server, after calling ABORTDATASTORE(),
> 'ReadSyncSet' is done and items are read from the database as part of
> 'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
> Shouldn't the engine skip these steps because the store has already
> failed?

Yes, it should but a check for isAborted() was missing after calling the <datastoreinitscript>. I have
added it now (bc0e54ca12 (Added check such that if <datastoreinitscript> calls ABORTDATASTORE(), the
abort gets propagated)), but I'm not sure it will improve the situation, as it will cause the entire sync to
stop, not just the datastore (because a problem in initializing the sync is considered a fatal error and
will lead to a AbortSession() (at syncagent.cpp:1171). On the other hand, I don't think just suppressing
operations on that single datastore would help a lot - most servers will expect a full sync cycle or then get confused.

We could check at syncagent.cpp:1171 if the abort reason status is zero (i.e. ABORTDATASTORE(0) called),
and if so behave differently, i.e. just muting that datastore, but leave the sessing running. But as said,
I'm not sure that will help with many servers.

> There is SLOWSYNC(), documented as "returns true if session is a slow
> sync". I found that it also returns true on a client if the session is a
> refresh-from-client. Is that intentional?

Yes. Within the engine, the term "slow" sync no only covers the two-way slow sync, but the "refresh" syncs as
well, as these are conceptually slows syncs as well. I think the SyncML standard docs used the term like
this at some point. So:

sync mode	"Normal" variant			"Slow" variant
(Continue reading)

Permalink | Reply | 6 comments |
headers
Patrick Ohly | 2 Feb 2010 13:07
Picon
Favicon
Gravatar

Re: detecting slow syncs

On Di, 2010-02-02 at 11:23 +0000, Lukas Zeller wrote:
> Hello Patrick,
> 
> On Jan 29, 2010, at 19:49 , Patrick Ohly wrote:
> 
> > Another peculiarity: on the server, after calling ABORTDATASTORE(),
> > 'ReadSyncSet' is done and items are read from the database as part of
> > 'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
> > Shouldn't the engine skip these steps because the store has already
> > failed?
> 
> Yes, it should but a check for isAborted() was missing after calling
> the <datastoreinitscript>. I have added it now (bc0e54ca12 (Added
> check such that if <datastoreinitscript> calls ABORTDATASTORE(), the
> abort gets propagated)), but I'm not sure it will improve the
> situation, as it will cause the entire sync to stop, not just the
> datastore (because a problem in initializing the sync is considered a
> fatal error and will lead to a AbortSession() (at syncagent.cpp:1171).
> On the other hand, I don't think just suppressing operations on that
> single datastore would help a lot - most servers will expect a full
> sync cycle or then get confused.

Aborting the session is what we want - but only after looking at all
datastores that are included in the current message. The goal is to
detect as many datastores as problematic as possible, before aborting
and reporting the problem.

> We could check at syncagent.cpp:1171 if the abort reason status is
> zero (i.e. ABORTDATASTORE(0) called), and if so behave differently,
> i.e. just muting that datastore, but leave the sessing running. But as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Ohly | 2 Feb 2010 13:09
Picon
Favicon
Gravatar

Re: XML config fragments

On Di, 2010-02-02 at 09:18 +0000, Lukas Zeller wrote:
> One comment: Email sync is completely assymetric, so just copying the
> server side definitions will not likely result in anything sensible
> (even if the scripts would execute in the client, which they won't
> because they use server-only functionality).
> 
> I'd propose to move the email related definitions into the server folder.

I agree. I thought they might be useful, but hadn't checked that in
detail.

> Only a few devices (P800,P9xx and the 9500 communicator and some
> descendants of that) still have email sync, of course including our
> own WM and (with severely reduced features) PalmOS clients. For
> syncing with these, the server side email support was left in the
> sample, but beyond I'd say email sync is obsolete.

I agree, although it seems to get asked for occassionally.

--

-- 
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.
Permalink | Reply | 0 comments |
headers
Patrick Ohly | 2 Feb 2010 16:48
Picon
Favicon
Gravatar

peer-specific properties + Nokia N7120c

Hello!

When Congwu tested direct synchronization with the Nokia N7120c, he
found that certain workarounds were needed (see patch below). 

Congwu, I'm not entirely sure why the "TZ" property is needed when we
force using UTC. Is it for events coming from the device? In that case,
how is the DTEND value handled? What was the advantage of forcing UTC
when it supports TZ? Too limited range of recognized TZ values?

Suppose we have multiple devices which all need this special "TZ"
property. Lukas, is there a way to do this without adding one <property>
entry per device? I think we discussed this before, but did we come to a
conclusion?

Bye, Patrick

commit ecfc190c15d822e96cbeda14827fc41e67589f72
Author: Chen Congwu <congwu.chen@...>
Date:   Fri Dec 11 14:47:58 2009 +0800

    Synthesis Configuration: add remote rule for Nokia 7210c

    It handles UTC time but does not claim in the devInfo.
    Some fileld has limited lengh but does not claim.

diff --git a/src/syncclient_sample_config.xml b/src/syncclient_sample_config.xml
index 58e18af..cdbc003 100644
--- a/src/syncclient_sample_config.xml
+++ b/src/syncclient_sample_config.xml
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lukas Zeller | 2 Feb 2010 22:33
Picon
Favicon
Gravatar

Re: peer-specific properties + Nokia N7120c

Hello,

On Feb 2, 2010, at 16:48 , Patrick Ohly wrote:

> When Congwu tested direct synchronization with the Nokia N7120c, he
> found that certain workarounds were needed (see patch below). 
> 
> Congwu, I'm not entirely sure why the "TZ" property is needed when we
> force using UTC. Is it for events coming from the device?

Events coming in "local time" from the device would be the only reason for *needing* a TZ.

> In that case, how is the DTEND value handled?

This is automatic. When a TZ/DAYLIGHT is encountered, the time zone derived from it becomes the "item time
zone", which means that any non-UTC (=non Z suffixed) time value found in the vCalendar entry
automatically is interpreted in this zone. The assignment of "TZ" (and "DAYLIGHT") to the "DTSTART"
field is only relevant when generating a vCalendar item - it means that the time zone of DTSTART is used to
generate an appropriate TZ/DAYLIGHT (while the DTEND, RR_END etc. fields could have other zones assigned).

> What was the advantage of forcing UTC when it supports TZ?

I would not trust an implementation that has the TZ in the wrong place (it does not belong into VEVENT, but
outside according to vCalendar 1.0 specs) to do anything useful with it. Moreover, TZ alone is pretty
useless without DAYLIGHT in most zones.

So sending in UTC is much safer. If the receiver gets TZ correctly, all the better, but if it does not, then at
least the absolute time will be ok.

> Suppose we have multiple devices which all need this special "TZ"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chen, Congwu | 3 Feb 2010 06:36
Picon
Favicon

Re: peer-specific properties + Nokia N7120c

Lukas Zeller wrote:
>On Feb 2, 2010, at 16:48 , Patrick Ohly wrote:
>
>> When Congwu tested direct synchronization with the Nokia N7120c, he
>> found that certain workarounds were needed (see patch below).
>>
>> Congwu, I'm not entirely sure why the "TZ" property is needed when we
>> force using UTC. Is it for events coming from the device?
>
>Events coming in "local time" from the device would be the only reason for
>*needing* a TZ.
Right, 7210c will always send "local time".

[...]
Lukas answered your questions quite well, I agree with him.

Best Regards,
Congwu
Permalink | Reply | 0 comments |
headers
Patrick Ohly | 3 Feb 2010 08:20
Picon
Favicon
Gravatar

Re: peer-specific properties + Nokia N7120c

On Di, 2010-02-02 at 21:33 +0000, Lukas Zeller wrote:
> If that's not sufficient, I'd propose extending the rule matching
> mechanism itself according to the multiple-rule capabilities that are
> already present: using <finalrule>no</finalrule>, the search for
> matching rules can be continued, and options specified by the rules
> will be accumulated. However only the last matching rule counts as the
> "current" rule. This could be enhanced as follows:
> 
> a) collect all rules that did match in a list, such that we can have
> multiple "current" rules.
> 
> b) add a <includerule> option for rules, such that a specific rule
> (say: "7210c") could activate other more general rules (say:
> "needsTZinVEVENT") which would also be added to the "current" rule
> list. Things like that TZ could then be made depending on such a
> general rule rather than the device rule itself.
> 
> This would be reasonably easy to implement (I can do it if we agree
> that this would be a useful solution) and would allow quite structured
> rule trees without repeating common parts.

I think it would be useful to have and if you could implement this, we'd
certainly appreciate the help.

Conceptually it is similar to how I did compatibility hacks with CD
writers: implement certain workarounds and make each of them depend on
its own flag. Then when detecting a certain model, turn the right flags
on. This worked well. In this case, the meta rules that don't match any
particular device take the place of the flags. As an additional benefit,
workarounds can be triggered both for such general "flags" as well as
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lukas Zeller | 3 Feb 2010 09:58
Picon
Favicon
Gravatar

Re: peer-specific properties + Nokia N7120c

Hi Patrick,

On Feb 3, 2010, at 8:20 , Patrick Ohly wrote:

>> This would be reasonably easy to implement (I can do it if we agree
>> that this would be a useful solution) and would allow quite structured
>> rule trees without repeating common parts.
> 
> I think it would be useful to have and if you could implement this, we'd
> certainly appreciate the help.
> 
> Conceptually it is similar to how I did compatibility hacks with CD
> writers: implement certain workarounds and make each of them depend on
> its own flag. Then when detecting a certain model, turn the right flags
> on. This worked well. In this case, the meta rules that don't match any
> particular device take the place of the flags. As an additional benefit,
> workarounds can be triggered both for such general "flags" as well as
> for specific models.

Thanks for the approval of the concept, so then it's coding time for me :-)

Best Regards,

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

Gmane