Re: [coldsync-hackers] ColdSync::PDB and syncing with web-enabled groupware

[Christophe Beauregard <christophe dot beauregard at sympatico.ca>]

On Saturday 04 October 2003 10:42, Nicola Fankhauser wrote:

> is ColdSync::PDB correctly showing which records were modified on the
> palm?

Yes, depending on which method you decide to use.

ColdSync::PDB is basically an object oriented wrapper around the DLP 
protocol. It's more or less a perl version of PalmSource's Sync Manager 
API.

The specific DLP commands to iterate through the modified records on the 
Palm are dlp_ReadNextModifiedRec and dlp_ReadNextModifiedRecInCategory in 
ColdSync::SPC. ColdSync::PDB has the nextModifiedRec([$catno]) method which 
is a wrapper around both.

In order to iterate through all modified records in a database using 
ColdSync::PDB, you'd do something similar to:

my $db = ColdSync::PDB->Current("rw");
while (my $record = $db->nextModifiedRec()) {
	my_sync_record( $record );
}

or, to iterate through the records in a particular category:

my $db = ColdSync::PDB->Current("rw");
my $catno = $db->catno('Unfiled');
while (my $record = $db->nextModifiedRec($catno)) {
	my_sync_record( $record );
}

You'd want to do more error checking that that, of course.

In the CVS repository, some ColdSync::PDB examples are 
coldsync/conduits/send-mail-2, coldsync/conduits/dump-dlpdbs and 
coldsync/conduits/recat. coldsync/conduits/zire71-photo uses the lower 
level DLP calls, although a ColdSync::PDB version would be trivial.

I think that sync conduits tend to get something of a bad rap for 
complexity. They're actually extremely simple to write from the API 
perspective, whether you're using ColdSync::PDB or just ColdSync::SPC 
calls. Depending on your goals a sync conduit can be easier to write than a 
dump/fetch pair.

The actual difficulty in usually in the logic for handling collisions and 
updates on both sides of the pipe. You've got to handle changes to a record 
on both machines, you have to know when a record was deleted on one versus 
being added on the other, etc. The sane way to handle it is storing the PDA 
record id on the server database. This isn't always possible or welcome 
(multi-user databases, POP3 mailboxes, etc) and you end up with all kinds 
of hacks to make it work. And if the PDA gets synched with more than on 
server you're just asking for pain. Compared to all that, the actual 
mechanics of moving data from the desktop to the PDA are trivial. That's 
why I've been content to stick with simpler stuff like sending mail ;)

Because of this, most people just use a dump/fetch conduit pair and rely on 
the generic sync to handle the hard parts.

Hmmm... You know, maybe I should code up a sample generic sync conduit to 
demo the whole process?

I also suggest browsing through the PalmSource conduit developer 
documentation:
http://www.palmos.com/dev/support/docs/conduits/win/C++SyncCompanionTOC.html

> Another problem is that coldsync supports only Palm devices

Yup. I don't think that's going to change anytime soon ;)

> (and not
> even all, like the recent thread about the tungsten T3) - nowadays, more
> and more mobile phones are used to manage contacts, calendar etc. And
> most of them support SyncML. :(

I suspect that compatibility problems will be solved very quickly once the 
right hardware gets into pilot-link/coldsync hacker hands. I look at broken 
things in coldsync as a challenge, not a road block, and usually get a fix 
fairly quickly. I'm not terribly unique in that way.

c.
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.