g4c9z at unb.ca
Tue Jan 18 15:40:37 EST 2005
Quoting Jason Day <jasonday at worldnet.att.net>:
> On Tue, Jan 18, 2005 at 03:05:55PM -0400, Adam Richard wrote:
> > What made it difficult? The J-Pilot conduit API (or whatever you call it) or
> > reading/writing the iCalendar file format?
> The biggest hurdle is the 3-way sync. You've got 3 sets of calendar
> data (J-Pilot, palm, iCalendar file), each of which is editable. So, to
> do a full sync, you need to sync the iCal file with jpilot, then sync
> jpilot with the palm, then you have to sync the iCal file with jpilot
> again. That's not too bad, as long as there are no conflicts. Who
> wins, though, if the same record is modified in all 3 places?
I see. That's why the best approach, it seems to me, is to have one program handle
(only) the synchronization between Palm and PC, with all synchronizing going between 2
.pdb files. Prior to synchronizing copy and convert the .ics to the PC's .pdb, and
afterwards copy and convert it back to the ics. All data modification on the PC is
done by whatever program you choose to use that stores its data as an .ics file. This
is what coldsync does, except it doesn't have the required conduits as far as I know.
But what if JPilot stored its data as .ics instead of .pdb? Then this much easier
approach could be used for synchronization. Other programs could work with and modify
the same data, and changes would be automatically be reflected in each program (so long
as either you're not using them both at once, or they use something like fam to detect
when the file has changed and reload it when it does).
In fact, I suppose it would already be possible to do this in the case of other programs
that can read/write .pdb files, except that JPilot doesn't save the changes in the file
until synchronization time.
More information about the Jpilot