[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] Titrax sync questions...



Thanks, this has clarified a lot! ;)  See my other reply for further 
questions.  

...Izzy

On June 13, 2003 10:48 am, Andrew Arensburger wrote:
> On Thu, 12 Jun 2003, Izzy Blacklock wrote:
> > I've been thinking about a future need for my conduit.  Eventually I'm
> > going to have to build a sync function.  What has me worried, is how this
> > will work with multiple files.  I guess the root of my confusion is that
> > I don't really know how the sync process works.  I have to admit, I
> > haven't looked at any sync conduits yet, so perhaps I'm worrying over
> > nothing.
> >
> > My biggest concern is on the timing and order of things.  Does a sync
> > occur after each file is read from the palm?  ie, Does the palm expect to
> > receive the sync'd version of a pdb right after it sends the pdb, or does
> > it send all the pdbs then wait for attempts to write data back?  Does
> > coldsync run the various conduits as it reads the pdb from the palm, or
> > does it wait until it has them all then run the conduits then write them
> > back to the palm?
>
> 	That's not quite how conduits work, or at least not sync conduits.
> 	Fetch and Dump conduits get complete PDB files to work with. Sync
> conduits don't. The purpose of a Sync conduit is to talk to the Palm and
> ensure that the database on the Palm is the same as the one on disk.
> 	For instance, the (default) generic conduit, which is a sync
> conduit, downloads each modified record from the Palm in turn, compares it
> to what's on disk, and then decides what to do: if the on-disk record
> hasn't changed, it replaces the on-disk record with the on-Palm record; if
> both have changed, and aren't identical (i.e., they've been modified in
> different ways), it creates new records so that both the on-Palm and
> on-disk databases have both versions of the record.
> 	Yes, this can get complex, but that's what a Sync conduit is
> expected to do.
>
> > I fear that the sync process is being run after each file is received.
>
> 	Not quite: part of the job of a Sync conduit is to read the
> on-disk file and the on-Palm database.
>
> > If
> > that is the case, building a sync process for titrax would be
> > problematic.  I would need to modify at 4 pdbs; TitrixNamesDB,
> > TitraxDataDB, TitraxNoteDB, and datebookDB.  If I trigger on the Titrix
> > pdb, how do I insure that the latest version of the rest of the files has
> > already been fetched?  How do I get the conduit to write out the other
> > pdbs after the TitrixNames conduit has finished?
>
> 	The only thing that leaps to mind is to have the conduit handle
> all four databases. As each one runs, it creates or checks a temporary
> file, and writes to it the current time and the database that it's
> currently syncing. If all four databases aren't listed in the file, it
> proceeds no further.
> 	Either that, or the first time it runs, it syncs all four
> databases and writes a timestamp somewhere. The subsequent three times, if
> the timestamp exists and is more recent than a few minutes, it doesn't
> bother.
> 	You could probably play other tricks along the same lines. For
> instance, if you sync all four databases the first time, then the next
> three times, neither the on-Palm nor on-disk databases will have any dirty
> records. You could use that as a flag.
>
> --
> Andrew Arensburger                      Actually, these _do_ represent the
> arensb@ooblick.com                      opinions of ooblick.com!
>                         Generic Tagline V 6.01

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