Re: [coldsync-hackers] Design logic of Sync conduits

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

On Sunday 22 February 2004 07:09, Marco van Beek wrote:
> Hi All,
>
> Since it would appear that I am going to have to write sync conduits
> earlier than expected (as it appears that the generic sync conduit does
> not update {appinfo}{categories} ), I have written a sort of design
> HOW-TO, which, if anyone has a spare moment, I would appreciate any
> holes that you can poke in it.

Right off, I see a problem:

    "When a record is edited on the Palm (which I will now refer
    to as Handheld ), what really happens is that the old record
    is marked as deleted, and the new record assumes a new,
    hopefully unique, {id} number."

It _can_ happen this way, but it usually doesn't. When the record on the 
Palm is changed, it's marked as dirty. But the record ID is usually 
unchanged. Some apps might handle updates by deleting the old record and 
adding a new one, but I've never seen it happen with any of the standard 
PalmOS apps. It certainly isn't a good idea to have the record ID change 
constantly since it introduces huge amounts of complexity into the whole 
sync protocol, but maybe you've been working with an application that does 
this?

For example, I just finished writing a conduit which keeps a Handheld record 
ID indexed DBM file on the Server. Changed record's are marked as dirty, 
but I can still test to see if the Server knows about the record by 
checking for the ID in the DBM database. When it comes to updating a record 
I already know about, I then have the option of deciding whether I need to 
download more stuff from the Handheld... it's for the Zire71 Photo 
database, so not downloading images that have only seen meta-data changes 
(name, notes, categories rather than image changes like rotations) is a 
huge performance gain. I couldn't do this if the record ID changed because 
I wouldn't even be able to search the Server side database for some kind of 
match since anything I'd match on would be volatile.

In a multiple Handheld situation, you'll probably be able to do the same 
sort of thing, except the Server will need to track the user id as well as 
individual record ids. This gets entertaining because each Server record is 
going to have a different combined id for each known Handheld.

Also, any document about sync conduits should reference the definitive work 
on the subject, the PalmSource document:
  http://www.palmos.com/dev/support/docs/conduits/win/C++SyncCompanionTOC.html


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.