It works! Sort of.

This weekend saw the first successful test of MacJournal's .mac syncing support. I pushed the data up to .mac, blew away the local data, and reconstituted it from the server. There are a few issues left to be dealt with however: ordering of entries, and locking of unencrypted journals. The former can probably be solved with some extra knowledge of SyncServices, but the latter might be different. It's not good to just toss the password up to the server in cleartext, so the password itself can't be synchronized automatically. That means that the locked state cannot be synchronized either. This is different than encrypted journals, however. Since that is just a big blob of anonymous data, it's safe to push around. It's only the unencrypted locked journals that will get "out of sync."

Then there's the matter of Palms. There's always been the hope that pushing the data up to .mac would allow Palms to pull it down. However, the more I learn about SyncServices, the less I think that can happen. For Palms to make some sense of the data, it has to be in a format that it can understand. An existing format can be extended to provide new data types. Apple provides three such formats for developers to use and extend. These three formats are Bookmarks, Calendars, and Contacts. Therein lies the problem: there is no basic "Notes" data format for MacJournal to use and extend. Therefore I had to devise my own data format, which is all well and good for the uses of MacJournal, but it means that the data are fundamentally incomprehensible to anyone else by default. Of course, once I publish the data format, any other application can read and extend the data to its own desires, but nothing can happen by default. This is just my theory so far; I've got more questions to ask of SyncServices.