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? > > Sort of: > 1 - if I export the contacts data in vcf format from the Android device > OneMediaHub "phonebook" then I see the appropriate category in the > exported file. > 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 > website).
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 -> device. > > > > 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 > device. 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 arbitrary combinations. See https://syncevolution.org/blogs/pohly/2011/state-syncing-open-source > One personal peeve, w/r/t contacts and the cloud services: the country > 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 you. SyncEvolution can run as SyncML server with Android hooked up to it via some SyncML client, like for example the one from Synthesis. See https://syncevolution.org/wiki/http-server-howto 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
