https://bugs.freedesktop.org/show_bug.cgi?id=54998
Bug #: 54998
Summary: disable PHOTO syncing for specific peers
Classification: Unclassified
Product: SyncEvolution
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: high
Component: SyncML
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Some peers, in particular older phones, have problems when being sent lots of
photo data. It may be more useful to exclude photo data altogether for such
peers.
See "[SyncEvolution] Sync failure due to large addressbook entires."
A possible solution would be:
- introduce a new session variable in the <sessioninitscript>
- set that variable in remote rules (see stripUID for an example)
or based on a new config property (see preventSlowSync)
- extend the <outgoingscript> for contacts such that it
unsets the PHOTO property before encoding a contact for the peer
if that session variable is set - see VCARD_OUTGOING_PHOTO_INLINING_SCRIPT
That should take care of sending data to the phone. Ensuring that the photo
doesn't get lost when receiving an update is harder. Something might be
possible with a custom <mergescript>, but I am not sure whether it really gets
invoked during a normal import.
Alternatively, dynamically updating the field attributes after parsing the
peer's CtCap would be a more elegant solution, because it would use existing
libsynthesis mechanisms:
- don't send properties to a peer which the peer doesn't support
(strip PHOTO when sending)
- preserve local properties not supported by the peer (preserve PHOTO)
However, implementing that will require considerable changes in libsynthesis:
- expose the field list attributes to scripts
- ensure that a script is called after parsing CtCap and before using the
field list (perhaps <datastoreinitscript> is suitable)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues
