Comment # 6 on bug 70950 from
(In reply to comment #5)
> (In reply to comment #4)
> > "picture-only" is not technically possible, because the text fields are
> > required to find matches with existing local contacts.
> > 
> > One could do a "picture-with-minimal-text-fields", but that is not going to
> > provide much benefits (none?).
> > 
> > If some future PBAP enhancement makes a "picture-only" mode more efficient
> > than "all", then we can still add that at that point.
> > 
> > Regarding "SyncType", yes, something like that can be added. But it is not
> > clear to me what you expect to see reported there. Is this a correct
> > description of what you had in mind?
> > 
> > 'text' - text-only sync active
> > 'all' - non-incremental text and picture sync active
> > 'incremental-text' - incremental sync active, currently syncing text
> > 'incremental-picture' - incremental sync active, done with text, now syncing
> > pictures
> > 
> > I would call that 'sync-cycle', to make it more explicit that this is about
> > what is currently going on and may change as we enter another cycle.
> 
> My idea of SyncType has few purposes.
> 1) Basically to know the exact moment when the text has been synced in order
> to browse the addressbook.
> 2) It happen to me writing a PIM gui few time ago, the module that usually
> initiate a task (i.e. StartSync) is separate from the module that show the
> results (i.e. GetPeerStatus) and maybe a third module would like to monitor
> the Sync to display the "Search" button in  the exact moment that the text
> has been synced.

Understood. So is the description of 'sync-cycle' and its values above okay?

> About the Sync Pictures Only.
> You are right, but it may be useful to have it.

Agree, but it's not technically feasible.

> I think we should consider to add few restrictions 
> i.e.
> "picture" require a previous sync with "text"

That doesn't help. When I do a PullAll(), even if it is in the same PBAP
session, I get no information about which vcard refers to which contact. I
still need the text properties in the vcard to find that match a second time.

> Below there is an Idea I had:
> I was just wondering how much effort is required to make something more
> generic for the incremental sync:
> Some kind of custom incremental sync setup inside the SetPeer api.
> By Default (the current one):
>    Stage 1: (list of all the fields except "PHOTO")
>    Stage 2: ("PHOTO")
> 
> But another possible useful configuration may be:
>    Stage 1: (FN,NAME,EMAIL,TEL)
>    Stage 2: (ADR,GEO,BDAY)
>    Stage 3: (PHOTO)
> All the other fields are not required for this peer.
> Some restrictions must be considered
> (i.e. the mandatory vCard fields are included by default in any stage)
> 
> This may help the customization of the VCard field required for the Sync
> because some PIM implementations may not require the full vCard but just a
> subset of it.

There are two different feature request here:
1. make incremental syncing more flexible such that any property can
   be turned off during a sync without removing it locally; PHOTO
   is currently the only property where that is possible.
2. configure the set of properties that the local side is interested
   in.

This sounds similar, but the implementation is different. The first one
involves sync logic, the second only one the set of data retrieved from the
peer.

The first one is harder. Right now, specific code has to be written for each
property which shall get that special treatmet. Adding more of them would get
ugly pretty soon.

Can you name a specific use case where you expect this to be beneficial?

The second one is already possible internally, there just isn't an API for it.
This would go into CreatePeer().

Either way, for the sake of avoiding feature creep, let's not mingle that into
this issue here. If you want this features, discuss their importance with your
colleagues and file new feature requests.


You are receiving this mail because: