gmane.comp.mobile.synthesis

Re: Sync mode extensions must be optional

Lukas Zeller — 2013-03-11T09:01:14

Hello Patrick,

On 11.03.2013, at 01:43, Patrick Ohly <patrick.ohly-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org> wrote:


Thanks! I merged them into luz branch, and will update master eventually.


I tagged it, but forgot to push the tag to gitorious, sorry for that. Done now.

Best Regards,

Lukas Zeller

Re: Sync mode extensions must be optional

Patrick Ohly — 2013-03-11T00:43:00

For SyncEvolution 1.3.99.3, I've extended the SyncEvolution
"SyncMLVersion" setting to control whether the extensions are enabled.
They are enabled by default because I don't expect many users to use
affected servers, whereas more user will want it on for use with
SyncEvolution as server.

I had already done this a while ago, but then noticed a problem during
release testing which caused me to back out the changes again because I
didn't have time to investigate.

It turned out that I didn't enable the feature on the server side.
Strictly speaking, that shouldn't be necessary, because the server will
only add the extensions when the client already sent his, so there
should not be any problem. But it makes sense to have this configurable,
just in case.

The master branch of libsynthesis on freedesktop.org is now based on the
latest gitorious master branch. Lukas, it contains two patches which you
might want to include:


commit 9b0c01cf2fff6701bdb026518048fc4b06a7072e
Author: Patrick Ohly <patrick.ohly-ral2JQ

Re: Def between iPhone and IOS simulator

Lukas Zeller — 2012-12-16T10:46:40

Hi Zhoulei,

On 13.12.2012, at 04:57, zhou lei <zhoulei-4BAh3P0U0Eva8LdYqivX5Q< at >public.gmane.org> wrote:


You can set it yourself, yes. But note that synclog.txt is not the <logfile> you want to see (that's only one line per sync).

The extended debug logfiles are automatically named after date and time and session ID and put into where <logpath> points.

If you can't access /tmp/sysynclogs, you can change the definition of the logpath config variable on line 9 of ios_syncclient_app_sample.xml

For example, to change the log directory to the app's document folder (which you can access from you Mac/PC using for example DiskAid http://www.digidna.net/products/diskaid, free functionality sufficient), change line 9 to:

  <configvar name="logpath" value="$(sandbox)/Documents"/>

This will make the app write the full logs to the documents folder.

Best Regards,

Lukas

Re: Def between iPhone and IOS simulator

Lukas Zeller — 2012-12-12T11:55:28

Hi Zhoulei,

can you create a syncML engine detail logfile? That would probably show what goes wrong.

If you are using the latest code from git and do a debug build, log generation into tmp/sysynclogs should be enabled, so you can just get the logs from there (see c6bbe8cb2c (iOS sample app: changed linking of libsynthesis and plugins to standard way to do it. Also improved default logging.) commit comment for details)

Best Regards,




On 12.12.2012, at 07:44, zhou lei <zhoulei-4BAh3P0U0Eva8LdYqivX5Q< at >public.gmane.org> wrote:

Re: Def between iPhone and IOS simulator

zhou lei — 2012-12-12T06:44:52

Hi, Lukas

When share this demo, and running it on ios 6, it works.  The log on ios 5:

< SyncML message #1 sent to 'http://192.168.2.179:8080/funambol/ds'

2012-12-12 14:40:19.389 ios_syncclient_app_sample[681:707] -
sessionStepWithCmd returned stepCmd:100 sta=0

2012-12-12 14:40:19.391 ios_syncclient_app_sample[681:707] runSyncStep
calling sessionStepWithCmd:10

2012-12-12 14:40:19.395 ios_syncclient_app_sample[681:707] -
sessionStepWithCmd returned stepCmd:101 sta=0

2012-12-12 14:40:19.399 ios_syncclient_app_sample[681:707] *** Got SyncML
Client progress Info: eventtype=6, targetid=0, extra1=0, extra2=0, extra3=0

2012-12-12 14:40:19.404 ios_syncclient_app_sample[681:707] runSyncStep
calling sessionStepWithCmd:10

2012-12-12 14:40:19.408 ios_syncclient_app_sample[681:707] -
sessionStepWithCmd returned stepCmd:102 sta=20015

2012-12-12 14:40:19.412 ios_syncclient_app_sample[681:707] -> unexpected
error 20015 while processing session step - discontinue session

2012-12-12 14:40:19.418 ios_syncclient_app_sa

Def between iPhone and IOS simulator

zhou lei — 2012-12-12T03:56:35

Hi, Lukas

For one question, the demo client could works fine on simulator, but can
not sync on iPhone. Using iPhone_dbplugin1, and server side is funambol.
Works with simulator, but not iPhone.

Regards
-Zhoulei
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis-zhcxFSZdvaOWpB8AXVHUkA< at >public.gmane.org
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Sync mode extensions must be optional

Lukas Zeller — 2012-10-11T10:27:58

Hi Patrick,

I found that some servers don't like the sync mode extensions in the devInf you introduced for SyncEvolution a while ago (crash syncs with misleading errors as apparently their wbxml decoders fail or something).

As I see no way to automatically control this, I added a session level config flag <syncmodeextensions> that must be set explicitly to enable the extensions. The default is off, to make sure current libsynthesis (master branch) users will no see any difference in behaviour once they update. For SyncEvolution, you need to add this flag to your config.

Best Regards,

Lukas


The patch (on gitgub, luz):

8226bd4988 (SyncModeExtensions: added config flag <syncmodeextensions> that must be set in config to enable non-standard sync modes to be added into config. This is because some servers fail to work when non-standard modes are present, so by default they are off now.)


Lukas Zeller, plan44.ch
luz-DkgZRUgWWJ3tRgLqZ5aouw< at >public.gmane.org - www.plan44.ch

Re: PBAP: one-way sync modes

Lukas Zeller — 2012-09-05T13:35:07

Hello Patrick,

On 31.08.2012, at 15:49, Patrick Ohly <patrick.ohly-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org> wrote:


Yes. I looked through the patches and everything looks ok to me. 


Yes. As I thought it was about time to clean up and update master as well,
I merged everything into my working branch and rebased it on luz_rebased,
as a "release candidate" for updating master real soon now...


luz_rebased is a candidate for master, you can take that, or create your
own rebased version, whatever fits better. Once this has settled,
I'll see how to update master.

Best Regards,

Lukas Zeller, plan44.ch
luz-DkgZRUgWWJ3tRgLqZ5aouw< at >public.gmane.org - www.plan44.ch

PBAP: one-way sync modes

Patrick Ohly — 2012-08-21T09:31:54

Hello!

For the PBAP caching mechanism in SyncEvolution I'd like to use the
Synthesis engine. I think that makes sense because the engine does a few
things which would have to be done manually otherwise (translate between
formats, finding pairs). The improvements below would also make sense in
other use cases.

At the moment the engine (or rather, SyncML) lacks a few things which I
need to change. I'm focusing on one-way-from-client syncing because the
server has a bit more control over what it does and because it matches
the SyncEvolution use case.

In SyncML, incremental one-way syncs fall back to a two-way slow sync
after a failure. If the server has an item which the client no longer
has, then the item will be recreated on the client, despite the
intention to only transfer data in one direction. Right?

This is undesirable in general (IMHO), and an absolute no-no for PBAP as
the client, because it cannot write the changes.

As a first step I would disable sending changes to the client if the
client asked

Re: [SyncEvolution] Recurrences with Nth weekdayof the month

Lukas Zeller — 2012-06-22T22:14:51

Hi Patrick,

On 22.06.2012, at 11:32, Patrick Ohly wrote:


I don't really know, because the iCalendar 2.0 RRULE parser was a contribution from someone years ago.

But for certain, many things from the iCalendar 2.0 RRULEs can's be mapped to vCalendar 1.0 and also probably not to the current internal representation (the RR_xxx fields). I guess the 2.0 implementation was done more or less along what the 1.0 implementation had already offered.

However, "second tuesday in month" type rules are supported, albeit in a slightly different form:

  RRULE:FREQ=MONTHLY;BYDAY=2TU;COUNT=2;
  (second tuesday in month)

It also works relative to the end of the month, e.g.

  RRULE:FREQ=MONTHLY;BYDAY=-1MO;COUNT=2;
  (last monday in month)

For full BYSETPOS support (which also allows to pick the Nth match from groups, like "last workday in month") the RR_xxx model would need to be extended, and the result would no longer be convertible into vCalendar 1.0.

But maybe it would already help to add limited BYSETPOS support to

Re: [SyncEvolution] Recurrences with Nth weekdayof the month

Patrick Ohly — 2012-06-22T09:32:25

[...]

In Evolution, yes, in libsynthesis, no. I can reproduce the problem and
noticed that the code (src/sysync/rrules.cpp, RRULE2toInternal()) bails
out because it doesn't recognize the "BYSETPOS" keyword.

Lukas, was that a conscious decision, perhaps because it cannot be
supported in combination with vCalendar 1.0, or just an oversight? What
would it take to support that?

Re: Funambol and large SyncML messages?

Patrick Ohly — 2012-06-18T08:20:56

The default message size is 150000 bytes. I vaguely remember such issues
for myFunambol, but chalked it up to "server isn't reliable" instead of
investigating.

Testing against OneMedia has not been successful at all, as in "most
tests don't run". First there was the issue with slow syncs causing the
server to report the 411 "try again later" error, then it started
throwing XML parser errors for a (as far as I can tell so far) correct
DevInf.


I don't know. I guess you could try asking Funambol (their mailing list
is now on SourceForge), but be prepared to be told to install a Funambol
client and emulate its behavior (that was the response that I got for
the DevInf issue).

Funambol and large SyncML messages?

Lukas Zeller — 2012-06-18T07:30:24

Hi Patrick,

occasionally, I get error reports from libsynthesis (iOS client) users which experience SyncML Error 511 ("server error") with Funambol/OneMediaHub servers. Analyzing these, it always boils down to a big (99kBytes) client message that the server apparently cannot handle. As the server does not send a MaxMsgSize, libsynthesis makes the message as big as fits into it's local buffer which is 100k by default.

My question - did you experience this large message size problem with Funambol as well? Or are you using a smaller message size than the default in SyncEvolution anyway?

I'm just wondering if reducing the message size could reliably fix that Error 511 problem - and if so how small the message size should be.

Best Regards,

Lukas


Lukas Zeller, plan44.ch
luz-DkgZRUgWWJ3tRgLqZ5aouw< at >public.gmane.org - www.plan44.ch

Re: Funambol + refresh-from-server => 417

Patrick Ohly — 2012-06-11T10:18:02

Ah, now I see what that parameter does. I've added a configuration
option, as you suggested. It turned out that I was overly optimistic
about all current servers supporting it: of course, Google didn't bother
supporting refresh-from-server.

Unfortunately one cannot use DevInf+remote rules to trigger the right
behavior, because the Alert is generated before DevInf is available. 

Grr. Looks like I will have to introduce a SyncEvolution configure
option for this.

Re: [PATCH] Improve readability of SyncML TK error messages

Patrick Ohly — 2012-06-08T14:09:17

Indeed. I wasn't aware of that convention when adding the code.


I've added that to my repo and also refined the CONSOLEINFO_LIBC code a
bit: instead of always using stdio, it lets the app override the actual
function.

I'm adding that because I get quite a bit of error output from the
SyncML TK which seems to be harmless. Some of reporting inside
libsynthesis duplicates my own reporting. So I'd rather disable console
printing dynamically and only enable it when the log level in
SyncEvolution is sufficiently high.

Re: Funambol + refresh-from-server => 417

Lukas Zeller — 2012-06-07T12:43:22

Hi Patrick,

Just changing getSyncStateAlertCode() call with the second argument set to false does the same trick. Because that second parameter switches between "simplified" (true) and "standard conformant" (false) client alert codes already.

  uInt16 alertCode = getSyncStateAlertCode(fServerAlerted,true);

Just because support for refresh-from sync modes was so bad in the early SyncML days, this parameter remained a constant.


That now applies to that second parameter of getSyncStateAlertCode()


The benefit of SyncML in general and libsynthesis in particular is that it works with real legacy systems. In fact, the more time passes, the more the main reason for using libsynthesis will become smooth legacy support. So I wouldn't want to switch standard behaviour here, and opt for a config flag.

Best Regards,

Lukas



On 06.06.2012, at 15:49, Patrick Ohly wrote:

Re: [PATCH] Improve readability of SyncML TK error messages

Andris Pavenis — 2012-06-07T12:32:00

It was mentioned together with different topic. The change was identical 
so I have tested it.
OK. In that case I agree. Such convention was not self evident

Andris

Re: [PATCH] Improve readability of SyncML TKerror messages

Lukas Zeller — 2012-06-07T12:24:44


Emails to me? Or to the list? I haven't seen anything about that LF topic before "[os-libsynthesis] [PATCH] Improve readability of SyncML TK error messages".


The convention throughout libsynthesis is that debug macros must output an entire message, not just a chunk of text, exactly for the reason that the output channel can do things like prefixing.
If a message line needs to be constructed from parts, that needs to be done outside of the macro by accumulating into a string variable, and then using the macro to output it as a whole.

SMLERRPRINTFX() and CONSOLEPRINTF() are no exceptions to this - that's why these should not be fed strings with trailing LF.

It's the responsibility of the output channel/macro to add an appropriate end-of-line character. That was missing in the CONSOLE_PRINTF_VARARGS() macro.
 

Agreed, but when following the convention that doesn't happen anyway.

Best Regards,

Lukas

Re: [PATCH] Improve readability of SyncML TK error messages

Andris Pavenis — 2012-06-07T10:43:02

If You verify my recent e-mails, you'll find exactly the same suggestion 
("\n" added as above).

CONSOLE_PRINTF_VARARGS (and other similar macros) can however be used to 
output a message in parts (not only entire message in one piece) in that 
case extra "\n" are not needed.  The same about the string "SYSYNC " 
which should only be present only at the begin of the message but any 
more in the middle. That was a reason why I dropped earlier suggestion 
which was identical with Yours and suggested other way.

Andris

Re: [PATCH] Improve readability of SyncML TKerror messages

Lukas Zeller — 2012-06-07T10:31:11

Hi Andris,

thanks for the patch. However, the SMLERRPRINTFX() macro, like all debug output macros across the entire library, is supposed to output a linefeed by itself. It also actually does so in my builds of libsynthesis, so if the LFs are missing in your output, it must be something along the path from SMLERRPRINTFX() to the actual output function.

I think the problem is in the CONSOLEINFO_LIBC shortcut output mode Patrick added this February (13ff1e4149 (logging + Linux: enable console output)), where CONSOLEPRINTF() is mapped to fprintf(stderr,...) without adding a LF. In my (iOS) build this new mode is not used, but output ends in a plain puts(), which does add the LF.

So my suggestion would be this:

diff --git a/src/sysync/sysync_debug.h b/src/sysync/sysync_debug.h
index 61d4cdd..68dce5e 100755
--- a/src/sysync/sysync_debug.h
+++ b/src/sysync/sysync_debug.h
< at >< at > -110,7 +110,7 < at >< at > TDebugLogger *getDbgLogger(void);
   // Because a lot of libs log to stderr, include a unique prefix.
   // Assumes that

Funambol + refresh-from-server => 417

Patrick Ohly — 2012-06-06T13:49:14

Hello!

It seems that Funambol has implemented some kind of protection against
excessive slow syncs: I can do a slow sync once fine. Doing it again
shortly afterwards (say, a few seconds later, as in automated testing)
results in a 417 "retry later" status for the Alert command (in the
SyncML response message).

They have not responded to my question about this behavior, so I don't
have an official confirmation that my interpretation is correct.

This server behavior makes one (otherwise useful) feature of
libsynthesis a bit troublesome: when an app requests a refresh from
server ("forceslow" = 1, "syncmode" = 1 in the binfile client API), then
the engine will ask the server for a slow sync instead of telling it to
do a refresh-from-server. In other words, the Funambol server has to
assume the worst (a slow sync) and applies its throttling even though
the client only wants to do a relatively benign "refresh from server".

I've checked that the Funambol server does many "refresh from server"
syncs without 417