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-syncml-server > > >. > > 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/TramontanePluginBuilderUserGuide/Introduction/Introduction.html > > > > 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
