[Bug 17345] New: transcode PHOTO data = avoid contact rejections by phones
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=17345
Summary: transcode PHOTO data = avoid contact rejections by
phones
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
From: Patrick Ohly <patrick.ohly(a)intel.com>
Cc: syncevolution(a)syncevolution.org <syncevolution(a)syncevolution.org>
Subject: Re: [SyncEvolution] Contacts rejected by peer - PHOTO size and
encoding
Date: Mon, 18 Apr 2011 09:14:49 +0100 (18.04.2011 10:14:49)
On Fr, 2011-04-15 at 06:59 +0100, Hevï Guy wrote:
> Once I finally set-up Syncevolution 1.1.1-2 so that I could at least
> do a one-way refresh of "Contacts" to my Nokia N86 8MP, I found that
> certain contacts would not sync; The resulting comment in the GUI was:
> "There were 22 remote rejections". Has anybody else experienced this?
> More importantly, has anybody found a solution?
Hevï sent me his log files. There were two problems:
1. Some contacts had photos that were so large that the contact
exceeded the maximum contact size supported by the phone (for
example, 206653 bytes where only 102400 = 100KB allowed).
2. Other contacts with photo are sent, but the phone reports an
error (415 status).
Hevï, were other contacts with photos transferred? The log only contains
the problematic contacts, so I cannot tell.
Do you see a relevant difference between a contact that was transferred
with photo and one which wasn't? Photo size or encoding (PNG vs. JPG,
for example)? If unsure, please send me the saved vCard of a contact
which was transferred okay.
The underlying question is this:
* Should PHOTO data be transcoded as part of syncing? This is
necessary at least for case 1 above and might also help with
case 2.
It could be added, but that leads to further questions:
* How does SyncEvolution decide which kind of PHOTO data will be
accepted by the peer? Resolution, format, ...
* If a photo was transcoded, how will SyncEvolution deal with an
updated photo sent by the peer?
A. Overwrite photo locally: allows updating photos on the
peer, but implies that a potentially higher resolution
version of the same photo gets overwritten when only
some other properties were modified.
B. Always preserve local photo data: adding a photo on the
peer would be possible, but not updating it.
Possible answers:
* Only transcode if it is detected during a sync that photos had
problems.
* Hard-code certain profiles, match them to DevInf reported by
device (based on max item size, for example).
* Preserve local photo data if transcoding was necessary.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=17345
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23967] New: asynchronous + batched item changes
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23967
Summary: asynchronous + batched item changes
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
When making changes to a backend (deleting/updating/adding items), the result
(success/failure + item ID + change tracking information) is expected right
away. That prevents interleaving execution of the change and processing the
next item and batching of multiple changes.
This is bad for performance when the backend needs to talk to some remote
resource (CalDAV/CardDAV server, ActiveSync).
It might be possible to address this by using the delayed item ID resolution
mechanism in libsynthesis. All the intermediate layers (TrackingSyncSource,
MappingSyncSource, APIs) also need to be changed. Finally the backends must be
changed to take advantage of this.
The first candidate for this is the ActiveSync backend where batching changes
would result in a considerable reduction of total sync runtime because of less
network roundtrips.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23967
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 24893] New: CalDAV: support tasks = VTODO
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=24893
Summary: CalDAV: support tasks = VTODO
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
The CalDAV backend is limited to exchanging VEVENTs. It might also not handle
collections well (or at all) that contain both VEVENTs and VTODOs.
The main reason for this is that none of the servers that SyncEvolution is
tested with support VTODO. Apparently sogo as server supports it.
For someone who isn't afraid of touching and
recompile the source code it wouldn't be hard to add.
A new class very similar to src/backends/webdav/CardDAVSource.h/cpp
would be needed. The implementation of the WebDAVSource callbacks would
be almost identical to CalDAVSource, the only difference is that the
class needs to pick collections containing VTODO, whereas CalDAVSource
picks collections containing VEVENT.
The rest of such a CalDAVTodoSource would be much simpler (= as in
CardDAVSource) because each item can contain only one VTODO, in contrast
to the multiple VEVENTs that can be in a calendar item.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=24893
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 19724] New: [webdav] syncURLs in the form of foo-%u-bar, rather than /foo/%u/bar don't work
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19724
Summary: [webdav] syncURLs in the form of foo-%u-bar, rather
than /foo/%u/bar don't work
Classification: MeeGo Platform
Product: OS Middleware
Platform: ---
Version: 1.2
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: salvatore.iovene(a)linux.intel.com
ReportedBy: salvatore.iovene(a)linux.intel.com
QAContact: jingke.zhang(a)intel.com
CC: patrick.ohly(a)intel.com, syncevolution-bugs(a)meego.bugs,
ext-iekku.huttunen(a)nokia.com
Estimated Hours: 0.0
BUG DETAILED DESCRIPTIONS
===========================================================
After commit 0d34ad46a6384c33e7dd84542956362d76809319, URLs like foo-%u-bar
might not work, because the insertion of the username in the path is not done
right away, but during the discovery phase, at each step. This means that there
might be trouble during the URL normalization from neon.
--------
Product: OS Middleware
Component: SyncEvolution
MeeGo Release: 1.2
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: salvatore.iovene(a)linux.intel.com
Assigned To: salvatore.iovene(a)linux.intel.com
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19724
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 19665] New: shared credentials
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19665
Summary: shared credentials
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From the "[SyncEvolution] configuration of CalDAV/CardDAV" mail thread:
We have "username", "password", "syncURL" properties. If "password" is
"-", then reading credentials looks up the password based on the given
username and the syncURL in the GNOME keyring (or soon, KWallet). The
"server" and "user" keys are used as search filter, with "server" equal
to the syncURL minus the method prefix (i.e., http:// and https://
stripped).
Storing a "password" not equal to "-" will automatically set the
password value in the keyring if its usage is enabled (on by default in
the D-Bus server, off in the command line).
Retrieving the config via D-Bus transparently retrieves the credentials
and sends them to the D-Bus client.
I'd like to extend this so that the username doesn't have to be know in
advance, and so that CalDAV and SyncML can refer to the same server
despite having different syncURLs.
Here's how:
"credentials = URI": Defines where credentials are stored. The empty
string (default) is the traditional approach.
"gnome://server=<server>[&user=<user>]" takes username and password from
the corresponding entry. "kde://" does the same for KWallet.
"keyring://" is an alias for the default keyring (depends on how the
binary was compiled and runtime environment). Saving a config will
always update the "credentials" property with the actual location.
Here are some use cases for this:
* The "google" and "google-calendar" configs will have
"credentials = keyring://server=google" set. In the case of
"google-calendar", both the sync and source configs have that.
That way all three configs use the same username/password
automatically. It forces command line users who do not want to
or can't use a keyring to configure with empty "credentials";
they can't share credentials.
* After configuring via the D-Bus interface, the command line will
automatically enable the right access method for the
credentials. It is no longer necessary to explicitly say
"syncevolution --keyring".
* A future extension would use either a different method or
additional parameters in the URI to define some other
authorization method. The current implementation must throw an
error when running into something it doesn't know.
Nothing needs to be done in the UI or the command line to support this.
The only changes will be in the current code which talks to the
keyring(s).
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19665
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23782] New: syncevolution.org binaries: KDE + Akonadi
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23782
Summary: syncevolution.org binaries: KDE + Akonadi
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
* nightly builds needs to be reconfigured to enable building the KDE support
* nightly testing needs to include KDE backends, both for unit testing the
backends and real combinations with peers; it depends on the KDE developers to
do something if issues are found in those tests (if any are found)
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23782
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23781] New: iCalendar 2.0 .ics file backend
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23781
Summary: iCalendar 2.0 .ics file backend
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Some people synchronize an .ics file by pointing the Evolution backend to it
(no longer works after EDS removed support for the file:// URI, see bug #23779)
or manipulating the ~/.evolution/calendar data (a hack which only works when
being very careful).
Write a SyncEvolution backend which reads/writes an iCalendar 2.0 file using
libical.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23781
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23780] New: integrate SyncEvolution into Evolution
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23780
Summary: integrate SyncEvolution into Evolution
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Evolution typically supports offline read access with some of its backends. It
does not support write access. SyncEvolution addresses that, but needs to be
configured and invoked separately. It would be nice to have seamless and
transparent syncing from inside Evolution. ActiveSync is getting integrated
like that at the moment -> extend that to CalDAV/CardDAV?
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23780
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23779] New: EDS: file:// uris
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23779
Summary: EDS: file:// uris
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Accessing an arbitrary database via database=file://<path to file> broke when
EDS removed support for such URIs. Reimplement that using the newer APIs in EDS
3.2 or 3.4.
Could be used to synchronize an arbitrary iCalendar 2.0 file, also useful for
testing.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23779
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months
[Bug 23778] New: EDS: efficient change detection
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=23778
Summary: EDS: efficient change detection
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
A set of EDS API changes were designed and implemented to make change tracking
more efficient:
http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-imp...
This is expected to land in EDS 3.4.
A first step towards using these extensions was done by Chris Dumez when
adapting the backend to the EClient API in EDS 3.0. Still needs to be merged.
The next steps are using the new calls if they are available.
Need to figure out how to determine and use that in syncevolution.org binaries
at runtime.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=23778
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 5 months