On Thu, 2013-01-31 at 10:35 -0500, Max Pyziur wrote:
On Thu, 31 Jan 2013, Patrick Ohly wrote:
> On Tue, 2013-01-29 at 16:40 -0500, Max Pyziur wrote:
>> On Tue, 29 Jan 2013, Patrick Ohly wrote:
>>> CATEGORIES were tested successfully with Onemediahub when SyncEvolution
>>> 1.3 was released; I just checked the logs, the server did include
>>> correct CATEGORIES data when downloading via SyncML. I did not check
>>> whether the UI made use of that data correctly.
>> Categories do travel with the data to Onemediahub (since when I sync a
>> device to OneMediahub data the categories move to the device also - I see
>> them if I do an export to a VCF file on the device)
>> however, unlike Memotoo, they don't show up automatically.
> So they are stored in Android, but not used in the UI?
1 - if I export the contacts data in vcf format from the Android device
OneMediaHub "phonebook" then I see the appropriate category in the
2 - if I explicitly add the category to Onemediahub Android device or on
the website, then those items associated w/ that category appear (in this
case MemoToo wins, since I don't have to go through this process on the
SyncEvolution as a SyncML client of Onemediahub has no API to create
categories. It can only send a vCard with CATEGORIES set. Looks like
OneMediaHub should scan incoming vCards to detect new categories.
>> My syncing (so far): desktop -> cloud service ->
> That doesn't answer how the cloud service -> device part is done. Both
> Memotoo and OneMediaHub work with arbitrary SyncML clients. I see on
> memotoo that for Android, both their own Memotoo sync (a Funambol client
> fork as far as I know) and the Synthesis client are mentioned.
> Either way, this seems to go wrong outside of SyncEvolution. You should
> better try to get in touch with the developers of the Android sync
> client to get your problem fixed.
I get it: SyncEvolution is between Evolution and a respective cloud
service or peer/local device, not between cloud service and Android
Exactly. The problem is that hardly any vendor (none!?) can afford to
write native code for all clients or support all clients that someone
else might have written. Therefore there is no solution which works for
One personal peeve, w/r/t contacts and the cloud services: the
field gets "homogenized" in the cloud service, notably Memotoo.
Several examples: if I have, say, an ISO-3316 two-letter code for a
country on my Evolution desktop - US (for the United States), Memotoo
converts it to "United States."
If I use a foreign term for a country code, say "Россия" (Russia), Memotoo
on the web page converts this to "Russian Federation"
Would someone know of an override for this (as in, leave my country names
as is, please)?
It is not uncommon that servers convert data into some kind of internal
representation - they have to, in order to convert between clients with
different representations. How that is done depends on the server-side
implementation. In the case of Memotoo, it seems to use an enumeration
internally instead of a plain text string. This is something that you
need to talk to Memotoo about, but probably it'll be hard to change.
The general problem of cloud services is that you are often not in
control. If you have the server-side source and run it on your own
server, then you have at least theoretically the possibility to modify
the behavior to suit your needs. In practice it depends on your time and
programming skills, or how much time the upstream authors have to
respond to feature requests. I don't know whether this is an option for
SyncEvolution can run as SyncML server with Android hooked up to it via
some SyncML client, like for example the one from Synthesis. See
OwnCloud or Kolab may be other alternatives. There are no HOWTOs for
setting that up in combination with SyncEvolution and it is a bit harder
than with SyncML (see https://syncevolution.org/wiki/http-server-howto
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.