python/palm-sync-core: new port

[HodsonTech]

Summary

A companion port to palm365-mac (#33861): the provider-agnostic Palm-to-cloud reconciliation engine, extracted out of that port so it can be shared with other cloud-provider packages instead of duplicated. A Google-backed package (palmgoogle-mac) depending on this is in progress.

This is a library, not a standalone tool -- it has no useful behavior on its own, only as a dependency of a provider-specific package that supplies the actual cloud API client (Microsoft Graph, Google, ...) and the field-mapping between that API's JSON shapes and Palm records.

What it does

• Reads/writes jpilot's .pdb/.pc3 files via pilot-link's libpisock, through ctypes.
• Tracks a stable confirmed/pending id-map (SQLite) so records survive repeated syncs without duplicating or resurrecting after deletion -- this is the part with the most hard-won correctness behind it (six real bugs found and fixed via live physical-hardware testing while building palm365-mac).
• Implements the actual sync orchestration (push-up, deletions, down-sync, the full bidirectional cycle) against an injected cloud-client object and field-mapper module, with zero knowledge of any specific provider's API.

Design note: one provider at a time

This engine has no notion of multiple cloud sources syncing the same data type at once, and deliberately doesn't need one -- a Palm device only has one calendar/contacts/tasks database, and two independent full-rebuild engines racing to write the same file is a real hazard. Provider packages built on this declare a MacPorts conflicts against each other rather than attempt to coexist (see palm365-mac's Portfile).

Testing

Tested via repeated local port -d install cycles, and validated as a real dependency by refactoring palm365-mac to consume it and running a full real HotSync round-trip (jpilot launch -> plugin_startup down-sync -> HotSync -> plugin_post_sync push-up/deletions/down-sync) with debug logging, confirming identical behavior to the pre-split monolithic version.

[reneeotten]

this looks like all AI coded stuff from a GitHub repo that exists for just a week. I'm personally no sure we're yet interested in incorporating any of this...

[HodsonTech]

this looks like all AI coded stuff from a GitHub repo that exists for just a week. I'm personally no sure we're yet interested in incorporating any of this...

I used AI to help write this, I'll be upfront about that, since I don't have programming skill myself. But I want to push back gently on "looks like AI slop" as the standard for judgment here, because the actual bar should be: does it work, and is it useful?

To that: there was no existing solution, on any platform, for syncing Palm OS PDAs to Microsoft 365 or Google. Palm Inc. died around 2008-2009, and with it Outlook/Exchange sync support ended. Nothing filled that gap since. I built this because I wanted it for my own multi-Mac setup and figured other Palm/PDA users in the retrocomputing space would want it too. Since JPilot is already a MacPorts package, and one that I've updated to work on apple silicon and modern GTK, adding these conduits here made the most sense rather than shipping it as some standalone thing.

This isn't untested code thrown at a wall. I've been building this over about two months, and I've run it through real hotsync cycles against an actual Palm Vx, including a fresh hard-reset device setup and full sync, and it worked correctly, over and over, in fact. I'm happy to walk through specific parts of the implementation, answer questions about how any piece of it works, or address any concerns you have about code quality directly. I genuinely want this to meet whatever bar you need it to clear, not just get merged as-is.