I'd like to be able to share my Calendar data (via some filters, such as category/icon/private flag) with other things such as Google calendar, ical files, etc.
I'd like to be able to share Contacts data with !SyncML clients such as my phone.
I think the best way to manage this is to sync the Palm with OpenSync.
This would mean these tasks:
- Improving OpenSync 0.30 (which they are doing a lot at the moment)
- Porting PalmSync OpenSync plugin to 0.30
- Improving PalmSync OpenSync plugin to deal with ContactsDB-PAdd instead of AddressDB
- Improving PalmSync OpenSync plugin to allow installing arbitrary PDB files (such as my iSilo files)
Then we'd need something that goes from OpenSync to jppy. At the moment, jppy read/writes PDB/PC3 pairs (via jpilot code.) So we could do one of these ideas:
- Have jppy read/write a straight PDB, and write an OpenSync PdbSync module. This would mean jppy setting dirty bits in in the PDB, and OpenSync's vapourware PdbSync module clearing them when syncing. This could probably share a lot of code with the PalmSync module.
- Change jppy's core format to something else, such as a directory full of vCard's/iCal files.
- Keep jppy the same, and have OpenSync write PDB/pc3 pairs.
To do the first option, jppy would want this kind of interface:
jppy.setprovider(jppy.providers.pdb("/tmp/files/")) # use a set of plain pdb files jppy.setprovider(jppy.providers.datebk6(jppy.providers.jpilot_tx()) # use pdb/pc3 pairs, wrapped in a DateBk6 wrapper
To write this, we'd match the functions in jpilot.i using stuff from pisock.py/straight pilot-link.
The second option would be quite a bit of work, and I'm not sure how I'd pick a new core format...
The third option would allow jpilot to still be used as a Calendar GUI for now, as I don't have one and I expect the Sunbird OpenSync module isn't ported to 0.30 yet. It would require:
- Keeping jppy the same, so jpilot and jppy would both write pc3 based adjustments to the pdb.
- The OpenSync module would read the changes from the pc3 to feed back to OpenSync. The module would then write out a new PDB containing changes from both sides, and zero out the pc3.
This feels like the best idea for now. It would probably require some code from jpilot (same as jppy uses), which might be a license problem. Jpilot is GPL, OpenSync core is LGPL, and their Palm module is LGPL. Maybe I can ask Judd about the particular files I find I need.
I think the PalmSync module ( http://www.opensync.org/browser/plugins/palm/src/ ) could be made to both Sync via HotSync?, AND talk to a local pdb/pc3 pair, decided by the configuration at runtime. This means for my default setup, both sides of OpenSync? will be this same module.
For straight Palm <---> Jppy usage, it would be overkill to go from Palm <---> OpenSync xmlformat <---> Jppy considering both ends talk PDB. It would let OpenSync do three (or more?) way, with other databases (Sunbird, Google Calendar, etc... )
A first step would be to make sure OpenSync FileSync can deal fully with the vCard files that Palm and Jppy writes. This isn't really part of the above, but just makes sure OpenSync is sane. At the moment, FileSync seems to be confused by PHOTO data, so I should review the vformat to xmlformat convertor in OpenSync's core.
Other things which might be nice:
- Give jppy Contact objects (etc.) an .updateFromvCard() method. That sounds the same as clearing the object and making a new one, just keeping the same UID.
- Move jppy Contact/Event/Todo objects into pilot-link's python bindings.
After talking with Daniel from OpenSync, I understand a {jppy,jpilot}-sync module wouldn't need to deal with the packing/unpacking of Contacts (etc.) data, we could register to accept things already in that format. OpenSync has format-plugins and sync-plugins to deal with this idea.
I've asked Judd (of jpilot) what he thinks about moving the jpilot pdb/pc3 logic into a shared library. He has wanted to get ride of the pc3 files for a while, but I quite like them because they allow to undo everything since the last sync quite easily. There are other ways to do that, though (such as just keeping the previous pdb file around.)
