I’ve been doing a lot of research lately regarding PalmOS HotSync. My findings are rather frustrating. I’ve been trying to implement synchronization between a Palm with a built-in wireless network connection and a remote server. An appropriate conduit (= code implementing synchronization logic) has existed for the application for quite a while now for “standard” HotSync (= using a serial or USB cable to sync a Palm with a Desktop). That conduit has been well-tested and in use long enough to be trusted. The best of all worlds would be to put that conduit on the server and use Palm’s existing network HotSync capability to talk to it.
The Palm HotSync infrastructure assumes that a Palm belongs to a single user, and that the single user HotSyncs (synchronizes data) with some number of desktops. Of those desktops, exactly one of them can be designated the primary, which means that when a Palm tries to HotSync across a network, it will contact the primary desktop and sync with it over the network instead of a cradle. Setting this up is an all-or-nothing thing, though. You can’t have different primary desktops for each application. That means that a user can’t set up a network HotSync with a specific remote server without changing the same HotSync preferences used for all other applications on the Palm as well.
Now, normally this is what you want. In fact, it’s what you want so often that people who are knowledgable about Palms and HotSyncing may be wondering whether there’s something I just don’t get since I’m even talking about it. Really, though, what I need for this application is to have a HotSync profile that could be invoked from within my program on the Palm that caused a HotSync to occur using whatever the current network settings are, regardless of how the user’s “normal” HotSync is set up. I.e., if they hit a “sync” button within this application, I want to synchronize only that application, and I want to do it with a remote server. I could implement a custom TCP protocol (and in fact suspect that’s what I’ll have to do), but ideally I could just set up a HotSync profile programatically and tell it to run. At the very least, I should be able to save the user’s current “normal” HotSync settings, change them to be network HotSync to a given server, invoke a HotSync (that, ideally, gives status updates back to my application, but could show a HotSync dialog instead), then changes the user’s normal settings back after it runs. It would be a little dangerous (what if the device crashes before the user’s normal settings are restored?) but it would be functional.
All synchronization logic happens on the PC side of a Palm->PC connection, no matter what the physical link (USB, network, whatever). The remote server would, presumably, only contain a conduit for the one application in which it’s interested, so any other data on the user’s handheld would not be affected. There could be many different HotSync profiles on the user’s device: the one that they use for most syncing, plus one for each application that wants to synchronize with a specific remote server, if only the API were there…
Unfortunately, Palm doesn’t document an API or a database format for working with either network settings or HotSync settings. I’ve done a little bit of reverse engineering on it, but I’m afraid my kung fu may not be strong enough to figure out everything I need to know in a reasonable amount of time. One guy seems to have already done all or most of the work, but he charges US $500 for the source code, which is just a little extreme, at least for a small shop, to get access to information that Palm really should be providing as part of their API.
Really, what is Palm afraid of? If they would just document the damn functions, a whole new class of HotSync-using applications would become possible. They released an unsupported library a few years back that gave programmatic access to network settings, but not to HotSync settings, but they let it fall out of sync until, by OS 4.1, it no longer functioned. Currently, it looks like the only way to write a perfectly legitimate app like this is to place a significant configuration burden on your users, roll your own custom solution, or shell out the $500 to get a reverse engineered support library that is not guaranteed at all to work past OS 5.4 (OS 6 simulators are out, but the web page doesn’t mention whether this library works with m68k devices when run in OS 6’s 68k emulation environment).
I can somewhat answer my own question regarding what Palm is afraid of. If applications can start running their own HotSyncs programmatically to whatever servers they please, sychronization points could start to proliferate. You might have to start doing separate synchronization steps for each of your applications, instead of a single step for one. This is a major usability issue, and I totally agree that it would be a bad situation. On the other hand, you have cases like the app I’m working on. We already have a conduit that will always run when a normal HotSync occurs. However, it’s important that users be able to get updated data while they’re on the road, away from their desktops, when they may or may not have a laptop handy. We just want to run the same conduit we would during a normal HotSync, but we don’t want to force our clients to make their personal desktops available through whatever firewalls they may have in order to enable network HotSync, and we don’t want to force them to purchase a set of licenses for an expensive commercial network HotSync solution, nor do we want to purchase one ourselves if we can avoid it, for various reasons.
One possibility I’ve looked into is trying to get a small DLP (= the link protocol used by HotSync; actually it has a few companion protocols as well, but I’ll us DLP to refer to them all) server like coldsync to compile and run on the device. Coldsync is one of the many available alternatives to Palm’s HotSync software, intended mainly to run on Unix OSes, but compilable on Windows as well (using Cygwin). From an initial inspection, it looks like Coldsync is capable of running either end of a network HotSync (either client or server), so if I can hack it to run on a Palm and talk to actual Palm databases, it would be like having a custom network HotSync emulator built into the app. Using the system’s would still be preferable, though. Another option would be to forget about DLP entirely and do a custom protocol over TCP connection, implementing just the bare minimum of DLP-like messages necessary to get this app to work. That’s a lot of work, too, for something the system could be doing for me if only the damn APIs were documented.
On the server side, things are just slightly better. Palm’s HotSync software is meant to sit in a logged-in user’s system tray. It creates dialogs and waits for user input, and it is not meant to be used with an arbitrarily large number of remote network users, so it’s not suitable for use as a system service (= daemon, = app that sits around all day and accepts HotSync requests from arbitrary users over the network and never tries to talk to a local user b/c there probably isn’t one). There are some commercial alternatives, and there are some open source alternatives. The open source alternatives are very attractive (especially coldsync, which seems especially elegant to me from what I’ve seen so far), but their downside is that they do not work with applications written to the Palm HotSync API. They implement their own APIs for implementing conduits. So, in order to get an existing API to work with one of the open source servers, I’d have to write a bridge. That’s a task I can handle (and which might be useful to other people, once done), but it’s still frustrating. Palm’s been really (really, really) slow dealing with the issue of Enterprise Synchronization (which is really what all this boils down to): the first Palm came out in about 94-96 time frame (not sure exactly), and by 2005 one would think that viable multi-user HotSync would be part of the PalmOS infrastructure, not a high-cost, high-frustration extra.