Running in parallel to the syncing efforts are Blogger/Google’s ongoing problems with third-party applications like MacJournal. There were a lot of problems when the new Google/Blogger (Glogger?) beta came out that extended beyond the beta area of the site and well into the “regular” portion that we all know and love. They fixed most of the problems within a week, but a lot of people are still having trouble posting to the Bloogle. It seems to happen all the time for some people, and not at all for others (like me, unfortunately). The error manifests itself as a cryptic message returned from the server: “Moved Permanently.” I don’t think there is nothing I can do on my end to avoid this as it seems it is entirely on the server side. Other third-party application developers are seeing this, according to their own developer mailing list. So I guess the best thing to do right now if you are seeing this problem is to email the folks at Bloogger and let them know your username and the problem you are seeing. Hopefully this will get resolved soon.
Thursday, September 07, 2006
Monday, September 04, 2006
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.
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.
Subscribe to:
Posts (Atom)