On Tue, 2009-09-08 at 10:36 +0100, William Uther wrote:
I've had a brief look at building syncevolution for the mac.
It
looks like it is going to be more work than I thought. Libsynthesis
itself doesn't build on a mac (there are some linker options that it
has hard wired in src/Makefile.am that aren't supported by ld on the
mac, specifically "--version-script", and disabling shared libraries
fails in other ways).
The usage of --version-script could be made configurable. I'm not sure
what the corresponding mechanism is on Mac OS X, but to get started
ignoring this aspect shouldn't be a problem.
How does it fail without shared libraries? The --version-script would
still be passed, but besides that I don't expect problems (famous last
words...).
I then started looking at what I was trying to do a little more.
I
want my Mac to Sync with my Android phone. I don't really want an
external server, which is why I was somewhat interested in your direct
synchronisation plans:
<
http://moblin.org/documentation/syncevolution/direct-synchronization-aka-...
>.
But that then starts to look very like Apple's iSync setup.
Yes, there are similarities. I've never used iSync myself, but the idea
and use cases are certainly similar.
They
have what appears to have started life as something like SyncML
server. It never reached full SyncML server status, but it does do
many similar things. For example, it synchronises nicely with SyncML
phones over OBEX (I used this before I got my android phone).
Then they must have a full SyncML server. I suppose they simply don't
expose it as one via HTTP. How capable it is is another question. I have
seen Apple documents where they specify exactly what the vCard has to
look like to be understood by iSync. It was very limited, considering
today's PIM capabilities. But perhaps that has changed and they can
support devices of different capabilities.
iSync supports plugins that look vaguely similar to 'sever
stubs'
mentioned in the moblin document above. They seems to do some extra
processing though in that they can map from Apple's internal
representation back down into simpler representations for phones
(which sounds vaguely similar to what is described here:
<
http://www.estamos.de/blog/2008/07/07/syncml-mac-os-x/
>). The Apple documentation is pretty awful:
<
http://developer.apple.com/mac/library/documentation/Syncing/Conceptual/T...
>
but if you actually play with the plugin-maker (it is part of the
MacOS Developer Tools available on Apple's website), it is pretty
clear that it is designed to make iSync talk to OBEX enabled SyncML
clients with different capabilities. Interestingly, in the Advanced
Options, it is possible to select "HTTP Server" as the SyncML Bearer
(rather than "Obex Server" or the default, "Obex Client"). I
haven't
found out how to use this yet.
This sounds like they have thought about the problem. Whatever you find
out, keep us posted, please.
--
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.