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

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



On June 12, 2003 03:55 pm, Rodney wrote:
> Izzy Blacklock wrote:
> > 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?
>
> Actually, I don't think it _really_ matters if
> it downloads them 1 at a time or not ... or even
> the order for that matter.  To be *most* flexible,
> and thus more likely to succeed, you need to be
> able to handle the files in any order.
>
> What I'd suggest is this, have a conduit that runs
> for each of the files 1 at a time and retain just
> which of your files have loaded; then when you get
> to the last one (the 4th one?) ... do your sync being
> assured all data is downloaded.  Then clear your
> downloaded file list to reset for the next sync.
> Since the conduit is going to live and die for each
> file, you cannot keep this list in memory.  Perhaps
> you could create a "semaphore" file in /tmp/ named
> just like the palm pdb.  Once you perform the sync,
> delete all the semaphore files.  There maybe other
> palm pdbs that coldsync downloads but none will be
> named like your 4 so you will be set for the next
> coldsync.

This makes sense, but still leaves one unanswered question.  If I build a 
conduit that simply creates "semaphore" files for each file as it comes down, 
until the last one has been read, how to I push the changes back for the 
other files once I've synced them with the local data?

I took some time to read up on the sync process.  I wasn't able to find any 
examples of an actual sync.  They all seem to be fetch/dump conduits.  I'm 
guessing what I need is to use the SPC protocol somehow.  There doesn't seem 
to be a lot of detail on how it works.  Is there an SPC opcode to send a pdb 
back?  I'm guessing I'd need to use the DLPC opcode in some way.  Are there 
any examples of this in action?  Is there more documentation someplace?  I 
found all the Dlp* man pages, but they all seem to C library calls.  Is there 
a way to use them from Perl?

>
> BTW, I think you were wondering how to add the
> database filenames and paths to the config files
> (right?).  You could simply store the path and
> filename in your semaphore file.
>
> Did I explain that clearly?

That would be another way to do it.  The way I've done it for my dump conduit 
makes sense, but a sync conduit using SPC, may not need any of this at all.  
From what I've read, I can simply read and write the files I need from where 
ever I want them.  I probably wouldn't even need to use the semaphore files. 
But thanks for the idea anyway.

Building a sync conduit sounds like a lot of work.  It isn't likely to get 
done any time soon.  At least not a full one.  I'm thinking I may play with 
the idea of building an archive sync conduit for the databook which would 
simply remove records older then x days and put them into an archive pdb file 
(if something like this already exists, I'd love to hear about it! ;).  This 
is where the majority of data will end up anyway (at least for my use) and 
would be the most difficult to manually purge old records for.  The Titrax 
records are easy to purge.  

Eventually, I'm thinking I'll look at the Titrax code itself and remove the 
need for three database files to store all it's data.  I think it should be 
possible to do everything with a single database, which would be a much 
cleaner approach for both the app and the conduit.  Another project for 
another day....

...Izzy

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