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

[Nicola Fankhauser <nicola dot fankhauser at variant.ch>]

hi christophe

first - kudos to all coldsync developers. it's a gerat application, and
actually the only one writing conduits for is as simple as it should be.

On Sat, 2003-10-04 at 18:26, Christophe Beauregard wrote: 
> > is ColdSync::PDB correctly showing which records were modified on the
> > palm?
> 
> Yes, depending on which method you decide to use.
> [...]
> 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 );
> }

looks very good to me.

> 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 

d'you know why? I can tell you: it's not documented. and pointing to the
source code of coldsync itself is not exactly what I call motivating -
the fetch/dump conduits on the other hand are fairly well documented,
with examples and everything, so people just assume it must be horribly
complicated, whithout even checking really. at least, that's how it was
for me yesterday when I skimmed over the coldsync conduit how-to (BTW,
why is the page for the link to the first page missing in the how-to?
it's very irritating.)

> 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.

that may be entirely possible - a small how-to would not be bad... :)

> 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 ;)

that's what I call synchronization - merge strategies, fast and slow
syncs, id mappings, last synced timestamps, cope with new and deleted
records. I helped implementing a SyncML-client/server last year and had
to deal with these things all the time...

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

nobody ever said that syncing was easy! :)

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

ahmm. that would be great, along with few lines documentation...

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

thanks for the hint.

> 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.

that's true dedication! :)

thank you for all the information.

regards
nicola

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.