|
From: Lukas Z. <lu...@pl...> - 2011-11-01 14:31:28
|
Hello On Nov 1, 2011, at 0:29 , deloptes wrote: > I was reading SySync_config_reference.pdf [p.17] where it states > [...] > > So it really sounds doable. Perhaps we need to build something on top as you > say (derived classes or wrapper or so). It's a matter of who calls whom. As long as you use libsynthesis as it is intended (doing all the SyncML work and call out to database access methods in the plugins when needed), it's straightforward. However, if there's a governing overall engine, which itself is designed to be the caller of plugin functionality rather than acting as a plugin, it gets more difficult. And as Patrick Ohly pointed out, multi-point sync between peers with different capabilities (supported fields) needs end-to-end awareness of these abilities or limitations. Between any two SyncML peers, libsynthesis has a lot of mechanisms built-in to obtain and use this meta information to avoid data loss in sync round trips. However, it was not designed to include non-SyncML peers into the capabilities negotiations. So sync between SyncML and non-SyncML peers would be rather uninformed, which usually leads to loosing data in round trips or creating duplicates. That's the real challenge in a multi-technology sync. > I would love also to read more about the JNI interface too and evaluate all > possible options. Perhaps it is easier to implement something in java > despite it will cause an overhead. > I think I'll spend the time around Christmas not in coding but reading the > documentation :-) as it looks more sophisticated. The JNI interface is not part of the opensource libsynthesis. > Something else: Do we need these http and ds client and server (that you see > in libsyncml/libopensync-plugin-syncml - I didn't got it at 100% until now, > because I have been using the obex-client in the config and I've never > looked what is going on. libsynthesis has no transport built-in, so you can use whatever you like. The examples from libsynthesis are all http, because OTA sync (over the air, internet based) was what actually was the demand of Synthesis AG customers at the time the library was developed. OBEX based SyncML mostly took place in the walled gardens of phone manufacturers, who had their own implementations. That has changed of course with SyncEvolution which offers both OBEX and http based on libsynthesis - and which has become, by far, the most advanced use case for (and contributor to) libsynthesis. Best Regards, Lukas Zeller, plan44.ch lu...@pl... - www.plan44.ch |