Hi Patrick,
On 01/31/2012 08:38 AM, Patrick Ohly wrote:
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.
That seems very interesting indeed for our use-cases. In this case the
requirement would be that the backend is able to keep some context
(session) from one pass to the next.
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?
Yes, that would be the most obvious approach.
Cheers,
Mikel
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
