On Mo, 2012-01-30 at 19:03 +0100, Mikel Astiz wrote: > On 01/30/2012 10:32 AM, Patrick Ohly wrote: > > On Mo, 2012-01-30 at 08:57 +0100, Mikel Astiz wrote: > > While talking about use cases, let me point out the big (sic!) elephant > > in the room: how should a PHOTO be handled in a "one-way" sync? The goal > > has to be to make such a sync as fast as possible in the normal case > > (all data already available locally). > > > > We can't avoid retrieving the full address book, because we need the FN > > to find matches. Can we ask for a subset of the data, most notably > > without the big PHOTO property? > > Yes, we can do that. It would be exactly like that, having a first pass > without the PHOTO property and later a second one for this purpose. I > still have to think how this two-pass approach would be possible using > SyncEvolution.
I'm currently thinking about that myself. There are other use-cases for it, for example the issue with the SyncML client side detecting that it has more changes pending at the end of the normal sync. I'm leaning to extend the internal SyncML session so that both sides just enter further send/receive cycles until no further changes need to be transmitted. > > Let's assume we can and will do that during a "one-way" sync. It'll > > reduce memory and BT bandwith usage. We'll be able to identify new and > > removed contacts. The drawbacks: > > 1. A new contact will be stored without PHOTO. > > 2. A modified PHOTO will not be recognized as modified. > > > > We could add some code which pro-actively reads all new contacts *within > > the same PBAP session* (because we still have the valid PBAP IDs of > > them). The second problem is harder. To find all modified PHOTOs, we > > have to read all of them, which puts us back to the situation that we > > wanted to avoid. > > > > Perhaps it would be acceptable to not refresh photos during sync? > > Instead this could be done in the background when a local contact is > > actually used. The drawback there is that the PBAP session and the > > information about the contact's PBAP ID in that session is most likely > > gone, and thus we would have to search for the contact via PBAP (full > > name, phone number, ...) > > As you mention, the first point should not be a problem as long as we > keep the session alive for the second pass. However, as I mentioned > before, I don't see how this could be integrated in SyncEvolution. > > Regarding the photo modification detection, that's something the > protocol makes kind-of difficult anyway. It's a shame that the REV > property in PBAP is not more widely used. So the plan would be to always read all photos to detect which of them 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
