next up previous contents
Next: Further information and links Up: Introduction and General Previous: Introduction and General   Contents

Introduction

One of the greatest assets of the handheld computers is their ability to interconnect with other applications. KPilot supports this capability through conduits. A conduit is a small separate program that talks to KPilot during the hot sync. The conduit translates between the Palm Pilot and the application you're syncing with.

For KPilot to be a really usable synchronization application, it depends on third-party developers to enlarge the conduit gallery to other applications. In particular, I want to encourage developers of Palm applications to provide not only a Windowsconduit, but at the same time put some effort in providing also a conduit for Linux and other platforms. This is also the reason why I'm writing this tutorial: To encourage third-party developers to write conduits for KPilot.

I will show the process at several examples:
First, the general framework (library, factory etc.) for a conduit is presented in section 2, then in section 3. I will describe how you can write a configuration dialog for your conduit. These two sections will use the malconduit (AvantGo conduit) as an example. The synchronization part (the conduit class) will be described in the next few sections. Section 5 will show a very simple synchronization at the example of the AvantGo conduit, where we will use the functions of an external library which will do the synchronization for us. In section 6 I will show a synchronization process where one file on disk corresponds to one database on the palm, and where no conflict resolution and no record comparison needs to be done, because we have to copy the whole database either from or to the handheld. The particular example there will be the docconduit which synchronizes text files on the harddisk with PalmDOC documents for AportisDoc, TealDoc, MobiPocket Reader, Gutenpalm etc. on the Palm. Finally, I wanted to show an example of a record-based conduit, but then decided it would be too extensive to replicate all the complex sync and conflict resolution code. Instead I refer to the addressbook conduit, which you should be able to understand quite well after studying the other conduits explained in the previous chapters of this How-To. Using KDE's KitchenSync general synchronization framework for syncing will be the topic of section 8, where I give some argument why we do not yet switch to kitchensync yet.


next up previous contents
Next: Further information and links Up: Introduction and General Previous: Introduction and General   Contents
Reinhold Kainhofer 2003-01-13