First a little background on pilot databases would be useful. Each database on the pilot is divided into multiple records. Each record is a specific entry into the database. For example, one address in the Address Book corresponds to one record in AddressDB. Each record has a unique id assigned by the pilot when the record is created, and an index number in the database. The index numbers get reused, for example if you delete the second record from the database then create a new one it will fill in the empty slot and become index number two. However, it will have a unique ID number. (The moral of this story is only use index numbers when you need to iterate through the whole Database, otherwise use the unique record id.)
When a new record is created by the user on the local side, it is inserted into the backed up copy of the databases but given a unique ID of 0. When the syncing occurs this record is installed on the pilot and the pilot will return with the new unique id for it. This same process happens with a conduit. If two records have the same unique id they will overwrite each other.
Lastly, the conduit is requested to hot-sync whenever KPilot is hot-syncing with the pilot. During this time the conduit asks KPilot if there are any modified records on the pilot and should back them up into the program the conduit syncs with. Then, the conduit checks to see if there are any locally modified records and asks KPilot to put those on the pilot. Once finished, it exits gracefully by a
emit syncDone();and KPilot will continue with the next conduit.
In the next few sections I will present the most important classes KPilot provides to the conduit programmers, and after that I will show several examples of different conduits.