[Kolab-devel] Kolab and PDA synchronization

[Bernhard Reiter]

Hi Guillaume,

Am Donnerstag, 8. September 2005 10:45 schrieb guillaume leclerc:
> Hi everybody, I currently work at AtolC&D on Kolab2 and more precisely
> on a solution for synchronizing PDAs.

welcome to the Kolab community.
Syncing with PDAs or other devices is an interesting topic.
Unfortunately there do not seem to be simple solutions.
 
> Indeed, regards to the multiple pocket devices (Pocket PC, Palm,
> phone cell,...), it seems to be interesting to implement to Kolab2 a
> solution, that will allow a synchronization between Kolab2 and such
> devices.

There are two approaches: 
a) sync the device with the client aka Outlook or KDE Kontact
b) have another client running on the server, so it will feel like syncing
with the server

> It already exists such a thing based on Windows system with Outlook, but
> nothing based on Windows or Linux systems with client such as Kontact,
> Aethera...

There is limited support for Kpilot in the KDE world.
Real testing has been going on with Palm like devices and its support is more 
or less "beta" quality. 

> Purpose is then to implement a solution on Kolab for synchronizing
> multi-device on different platforms (above all Windows, Linux), and not
> only for Outlook. The informations to transmit will be contacts,
> calendar events, notes, and task lists.

Information about emails probably should also be considered,
as this is the prime application of a Kolab solution.

> I had already a look on existing pilots and projects, that permit this :

Thanks for the list, evalutating existing solutions is quite important.
Would it make sense to put this in a wiki development corner?

> - kpilot (http://www.slac.com/pilone/kpilot_home/hardware.php
> <https://intranet.atolcd.com/horde/services/go.php?url=http%3A%2F%2Fwww.sla
>c.com%2Fpilone%2Fkpilot_home%2Fhardware.php>) seems to be quite mature, but
> based essentially on KDE and Kontact, for Palm devices, Sony Clié, Treo and
> Samsung

Our best horse so far.
Note that KDE plans to supercede Kpilot with Kitchensync, 
but Kitchensync active development for quite a while.
I have not checked in a while, does anybody have news?

> - jpilot (http://www.jpilot.org/
> <https://intranet.atolcd.com/horde/services/go.php?url=http%3A%2F%2Fwww.jpi
>lot.org%2F>) is only available for PALM pilot on Linux
> systems
> - the project sync4j (http://www.sync4j.org/
> <https://intranet.atolcd.com/horde/services/go.php?url=http%3A%2F%2Fwww.syn
>c4j.org%2F>) for Kolab looks very good, supporting Windows Mobile PocketPC,
> BlackBerry, and Palm, running both in Windows and Linux. But it works
> only with the first version of Kolab.

While any solution would be step forward, it would be really cool, 
if the solution could be run completely on Free Software.
Many java solutions currently do not run on a Free Software java stack.

Another "should" is
that only user credentials are using for the sync,
thus a "client" running close to the server implementing the "sync server",
shall not have manager credentials or any other priviledge.

> - Multisync (http://multisync.sourceforge.net/news.php
> <https://intranet.atolcd.com/horde/services/go.php?url=http%3A%2F%2Fmultisy
>nc.sourceforge.net%2Fnews.php>) supports mobile devices, PDAs and cell
> phones (Sony Ericsson, Siemens, Pocket PC, Opie, Zaurus, Palm) but seems to
> work only on a gnome platform.
>
> To my mind, the synchronization will be done via the protocol SyncML,
> which offers a common language for communications between devices,
> applications and networks. (except if patents issues exists).

Actually I  am more concerned about how the concept will be brought together
then with the protocol itself.

If a Kolab Server and a full Kolab client have all the information,
how to we treat mobile devices that can only display, save or sync back
less of the information? How will the merge be done?
As a Kolab Client might be connected to more then one server,
e.g. think about one company, one familiy and one sport club server.
The point of most information seems to be the client then and not the server.

> To implement the solution, I think about a server solution (more than a
> client), with a common base and some specifics implementations depending
> on the device we use (but nothing is put in stone).

I believe that using a client approach would be the first to try.
Maybe a user then has several network servers that he or she can
leave instructions to update the mobile device.

Bernhard