Re: [os-libsynthesis] [SyncEvolution] EXDATE in iCalendar 2.0
Hello!
I've started to look at a workaround for this inside the Synthesis XML
configuration. My expectation is that if DTSTART is relative to a
timezone, then EXDATEs should also be relative to that same timezone.
UTC or floating do not make sense, because if the timezone definition
changes, those exceptions might no longer match.
Following that logic I came up with this snipped for the incoming
calendar event script:
// Make sure that all EXDATE times are in the same timezone as the start
// time. Some servers send them as UTC, which is all fine and well, but
// only if the timezone definition doesn't change. Also, libical does
not
// handle such UTC EXDATEs, so let's convert it while the UTC and
// time zone definition (hopefully) are in sync.
if (TIMEZONE(DTSTART) != "UTZ" && !ISFLOATING(DTSTART)) {
i = 0;
while (i Hello!
>
> Yanshuang found that Evolution and ScheduleWorld do not quite agree on
> the interpretation of EXDATE:
> http://bugzilla.moblin.org/show_bug.cgi?id=1805#c4
>
> The server sends a recurring meeting relative to TZID=Europe/Berlin with
> EXDATE in UTC time:
>
> DTSTART;TZID=/softwarestudio.org/Tzfile/Europe/Berlin:20090630T19
> RRULE:FREQ=DAILY;UNTIL=20090702T17Z;INTERVAL=1
> EXDATE:20090630T17Z
>
> Evolution (or, more likely, libical) does not recognize that the first
> instance of the event was cancelled and continues to show it.
>
> Evolution itself creates an EXDATE relative to the time zone:
> EXDATE:20090630T19
>
> Lukas, Mark, do you have any thoughts on this?
>
> Yongsheng might have found a similar issue with the Funambol server:
> http://bugzilla.moblin.org/show_bug.cgi?id=2422#c34
>
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
On Tue, 2009-07-28 at 17:49 +0100, Lukas Zeller wrote: > On Jul 28, 2009, at 16:48 , Patrick Ohly wrote: > > > Anyway, currently in SyncEvolution the performance difference isn't > > that > > large, so let's focus on the other aspect: the statistics are not > > incremented even if the engine does the deleting one-by-one. > > Ok, I didn't look up that one myself in the implementation before > replying, sorry. > > But thinking of it, I believe I did it this way intentionally. It very > much depends on point of view you have for the "deleted" count. For > myself, I prefer seeing only deletes issued from the remote side, and > I consider cleaning out the local DB before "reloading" the data not > as real part-of-sync delete operations. Of course, YMMV. Indeed. For me, the numbers in the statistics must add up: "items before sync" + "items added" + "items deleted" = "items after sync" ;-) It's a bit hard to tell what the users expect, but as we really present all these numbers (including the item counts) I think a mathematically correct interpretation makes more sense. > > Is this something that can or should be changed? > > Can certainly, should - IMHO for a generic sync engine it might make > sense to add an *option* to add these to the count. Fair enough. But I can also fix the statistics inside SyncEvolution. Let me have a look at that first, before you spend any more time of your vacation answering emails or worse, coding! -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
[os-libsynthesis] VTIMEZONEtoTZEntry() and \r\n
Hello! I'm currently testing with a libical which generates VTIMEZONE information with \r\n line endings. A while ago (Tue Apr 21 09:21:17 2009 +0200) I already fixed the extraction of the VTIMEZONE NAME. I must have missed at that time that extracting the other information from such a VTIMEZONE also fails because BEGIN:STANDARD\n and BEGIN:DAYLIGHT\n is not found. I'm now a bit torn about how to fix this. The brute-force approach is to replace \r\n \n\r and \r with \n to at the start of VTIMEZONEtoTZEntry() and keep the rest of the code as it is. But that wouldn't fix other callers of VStr(), which is a globally visible function. The other approach is to change VStr() and VPeeledStr() so that they work with arbitrary line ends. Any thoughts on this? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
On Jul 28, 2009, at 16:48 , Patrick Ohly wrote: This is the case I was worried about: "delete all" is fast *and* can return the number of items. I don't think that this is unrealistic. Don't SQL databases with one row per item fall into this category? If you really have one row per item, yes. But just add a bit of complexity with exception records etc. and relations, and it'll get difficult again. Anyway, currently in SyncEvolution the performance difference isn't that large, so let's focus on the other aspect: the statistics are not incremented even if the engine does the deleting one-by-one. Ok, I didn't look up that one myself in the implementation before replying, sorry. But thinking of it, I believe I did it this way intentionally. It very much depends on point of view you have for the "deleted" count. For myself, I prefer seeing only deletes issued from the remote side, and I consider cleaning out the local DB before "reloading" the data not as real part-of-sync delete operations. Of course, YMMV. Is this something that can or should be changed? Can certainly, should - IMHO for a generic sync engine it might make sense to add an *option* to add these to the count. Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
On Tue, 2009-07-28 at 16:06 +0100, Beat Forster wrote: > I'm happy to hear that it isn't a performance > issue. If it is the following strategy is > possible: If DeleteSyncSet is called, you know > that all items will be deleted, so delete them > and return 20030 and keep the number of deleted > items. After that, DeleteItem will be called for > the number of items. Just return ok for all of > them and give the engine a chance to count them. That should indeed work. > The engine has all information about the number > of deleted elements. Probably these deleted items > are currently not counted in case of > refresh-from-server. > I think this can be fixed. This sounds like a fairly easy fix - except that I don't know where to look ;-) Can someone give me a pointer or perhaps implement the fix right away? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
On Tue, 2009-07-28 at 14:26 +0100, Beat Forster wrote: > The only difference is mainly reading the sync > set (which must be done for all two-way-syncs > anyway). The performance difference is huge, if > you have just one command to delete all elements, > which is e.g. the case for our iPhone client. > But I'm not even sure if this command would > return the number of deleted elements. This is the case I was worried about: "delete all" is fast *and* can return the number of items. I don't think that this is unrealistic. Don't SQL databases with one row per item fall into this category? Anyway, currently in SyncEvolution the performance difference isn't that large, so let's focus on the other aspect: the statistics are not incremented even if the engine does the deleting one-by-one. Is this something that can or should be changed? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
Hi Patrick, just my comment: Usually the engine knows about the number of elements in the sync set, therefore no additional information is needed to get this count. In case of a refresh-from-server I assume the sync set will not be read, but the plugin could return 20030 if no ReadNextItem sequence has been done before. So the engine will remove element by element then and get the number of elements this way. I'm not sure I follow here. Suppose a database plugin implements the current DeleteSyncSet(). How does the engine know how many items were deleted? Is it possible without causing overhead (the main reason for the existance of DeleteSyncSync(), I suppose)? Efficiency is one reason, yes. The main reason however was the need for wiping metadata not directly visible in the sync when the entire sync set is being refreshed, vs. a incremental update. In particular, groups in the iPhone address book are added when first used, but are not refcounted (not deleted when empty). But when I do a reload device, I don't want such metadata to persist. As a plugin writer you can decide not to implement DeleteSyncSet(), and then the engine will read the sync set (IDs, modified status) as for any normal sync, and then issue DeleteItem() in a loop. You still can make use of the call to DeleteSyncSet() as an indicator the entire sync set will be deleted and wipe metadata - if you return LOCERR_NOTIMP the engine will still do a one-by-one delete loop. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] statistics about deleted items in refresh-from-server sync
On Tue, 2009-07-28 at 13:13 +0100, Beat Forster wrote: > Hello Patrick, > > my opinion is that this is not worth an API > change. DeleteSyncSet always expects to remove > all elements of the sync set, a return value > different to this is anyway not allowed and might > be interesting for statistics but in all other > cases very confusing. Yes, that's also what I thought. My last sentence should have said "API extension", like DeleteSyncSetCounted(). Do you also think that this is not necessary? > Usually the engine knows > about the number of elements in the sync set, > therefore no additional information is needed to > get this count. > In case of a refresh-from-server I assume the > sync set will not be read, but the plugin could > return 20030 if no ReadNextItem sequence has been > done before. So the engine will remove element by > element then and get the number of elements this > way. I'm not sure I follow here. Suppose a database plugin implements the current DeleteSyncSet(). How does the engine know how many items were deleted? Is it possible without causing overhead (the main reason for the existance of DeleteSyncSync(), I suppose)? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
[os-libsynthesis] statistics about deleted items in refresh-from-server sync
Hello! I think items that get deleted at the start of a refresh-from-server sync should be counted as part of the overall sync statistics. Otherwise we end up with a refresh-from-server sync which doesn't change anything but claims to have added items. We have an open issue about that in SyncEvolution: http://bugzilla.moblin.org/show_bug.cgi?id=3314 Originally I thought that this was caused by SyncEvolution, but after checking the call stack, I see that it is the DB API DeleteSyncSet() call (or its internal fallback) which remove the items without counting them. That call is defined as: /*! This routine deletes all datasets from the database * * @paramThe datastore context. * * @return error code * - LOCERR_OK ( =0 ), if successful * - LOCERR_NOTIMP ( =20030 ). For this case, the engine removes all items directly * - ... or any other SyncML error code, see Reference Manual */ _ENTRY_ TSyError DeleteSyncSet( CContext aContext ); If we add a retval (= DeleteSyncSet(CContext aContext, int *aNumDeleted), then we change the API and thus must introduce it as an alternative DeleteSyncSetCounted() (or something like that). I considered returning the number of deleted items as negative error values, but TSyError is defined as uInt16 and changing that might change some ABIs. It's hackish anyway. Any comments? Is fixing this worth an API change, if so, when? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
