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

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

On Sunday 22 February 2004 15:59, Marco van Beek wrote:

> Thanks Cristophe. You are, of course, right. I suspect that it only
> happens if a key field is changed (perhaps a field it uses for an
> index). I am working with the built-in applications, and I spotted this
> happening, and thought it was standard.

Strange. Looking at the source code for the Datebook (for example), it 
actually takes pains to keep the record id and index the same across 
updates, using the DmAttachRecord() call. Hmmm... Might have something to 
do with changing the sort position... That looks like it might throw things 
off.

Ah, here we go. The discussion of the unique id is in chapter 6 of the 
PalmOS Programmer's Companion, and reads:

	"The unique ID must be unique for each record within a database.
	It remains the same for a particular record no matter how many
	times the record is modified. It is used during synchronization
	with the desktop to track records on the Palm Powered handheld
	with the same records on the desktop system."

So if the unique ID is changing, it's definitely non-standard behaviour.

> I have updated the document with your input, and thanks for the help.

I have found another problem, I think:

   "Secondly, there is a remote chance that two Handhelds
   would create a new record with the same {id}, so the Server
   MUST control the issuing of {id} numbers."

I'm not convinced that the Server CAN control the {id} numbers. The unique 
{id} is supposed to be issued by the DmNewRecord() call. That's what I 
meant in my last e-mail when I suggested that for each Server record, it's 
going to have a different {id} for each Handheld and you're going to have 
to keep track of all this.

Other things:

   "Can we write to the HotSync log from inside the conduit?"

ColdSync::SPC::dlp_AddSyncLogEntry()

  "Do we need to reset the dirty flags manually?"

You can clear the flags of the entire database with dlp_CleanUpDatabase(), 
but that means dirty records will be "hidden" from any other conduit that 
relies on them. The generic sync, for example. When I write sync conduits I 
avoid messing with the dirty flags for precisely this reason.

> I also have a question about the SPC stuff. Once I open the DB (using
> dlp_OpenDB), can I write to the data in the same way I would with Fetch
> & Dump conduits?

Not quite. Not using the SPC API directly.

Also, algorithms which make sense when working with a local database aren't 
necessarily going to work well over an SPC pipe.

> The Palm::SPC man page gives the impression that I have to read the data
> in by using dlp_ReadAppBlock, and then write it with dlp_WriteAppBlock,
> but then all the writing would be done in one go, and fastsync's
> wouldn't work.
>
> If I use $PDB = &dlp_OpenDB(xxx), does it work as a handle in the same
> way as $PDB->load(xxx)? Am I just making this way too difficult by
> misunderstanding / over complicating SPC?

SPC won't do that itself. It's just a perl interface to the DLP/SPC 
protocol, which in turn is just a front end for various PalmOS managers... 
mostly the Data Manager.

ColdSync::PDB will seem a lot like Palm::PDB, at least from a record 
perspective. It doesn't handle appinfo very well... it downloads it and 
makes it available as per Palm::StdAppInfo, but it won't send changes back 
to the PDA. It can be done, but I didn't have a requirement for it when I 
wrote ColdSync::PDB.

There are some significant differences between ColdSync::PDB and Palm::PDB 
that you have to be aware of before you use it, too. Palm::PDB reads the 
entire database into memory, you do all your processing, then the changes 
are written back out. ColdSync::PDB databases are being changed on the fly 
on the PDA side of the pipe, which can be relatively slow and definitely 
not something you can back out of if you realize something went wrong. It's 
also a lot slower when you try dealing with the entire database, which is 
why you really need to pay attention to the dirty flag (using things like 
nextModifiedRecord() rather than iterating over @records, for example).

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.