Notes from conversations with Roger Binns on May 13 2004

Roger has developed a little wxWidgets based PIM that's open source and has had thousands of downloads -- in his spare time. It synchs phone #s and much other information (ring tones, pictures, speed dial #s) for a bunch of cell phones

OBEX - Object Exchange - comma separated values files, with arbitrary limitations on name length. Of course you generally have to code to the quirks of each phone.

Keeping data in synch when you don't control either set of data is a hard problem. For example, you might write a piece of software to synch between the Mac Address Book and a particular cell phone. This piece of software has to tell when the MAB has created, deleted, or altered a contact, or even a piece of a contact -- and it has to be able to tell whether the contact for John Doe was actually replaced by a new item of the same. It helps to have entry IDs for contacts or even for fields within contacts, so that the synch software can tell what's changed, basically constructing a transaction log. The problem is even harder when talking to the cell phone because some cell phones have fixed slots for phone numbers; sometimes the speed dials are inferred from the slot location in some wierd way. Numbers may or may not be ordered on different cell phones. Some support two numbers for the same contact, others don't... and if a user changes data on the cell phone that must be synchronized back.

Some phones limit names to 16 characters and in ASCII -- so unicode data is highly degraded.

How a PIM can be a good citizen:

• Have good entry IDs so that auxiliary software can tell what changed
• Persist the information that associates ring tones, pictures and arbitrary other data with phone numbers. You don't want to lose wallpapers when you synchronize your phone. Also provide a place to store foreign entry IDs.
• Also allow people to view and select arbitrary data stored in the PIM that came originally from their cell phone - e.g. let the user examine the picture & delete it or replace it. This is the problem of showing arbitrary data that we weren't aware of before the user added it, no matter where it came from.

Schema design

• Cell phones probably have limited "categories" or "groups" -- obviously a PIM which encourages users to have many groups, makes it harder to synch that to a cell phone.
• Remember the problem with dumping unicode to cell phones.
• Possibly have some way to pick a "primary" phone # so that the software knows which # to synchronize -- or mark a specific phone # as "this is the phone # that is synchronized with such-and-such a phone".

Synch tool design

• Maybe even go so far as to look at the quality of the information being synched to see which version to keep. E.g. if you synch your cell phone to your work computer, then later on to your home computer, should you replace the image on your home computer with the "new" image on your cell phone? Maybe not -- possibly the "new" image is the same one only degraded so that it fits within the limits. Possibly the only thing to do here is to actually compare the images.
• Some phones now store addresses, but others have memo fields where the synchronizer can put the address just as text.
• Have some way to store the order of the phone # as stored on the cell phone.

So, what about Chandler? As Mitch explained, we're interested in doing the right thing for the world we're in now, and then for the world we're moving into. You can't always do things right because of the lack of standards, cooperation. For niches you can craft something which is a decent hack, solves a problem in a specific way. We won't put all these things into our schema today, no ring-tones or wallpaper for the time being. But in the long run we can keep in mind these mappings, and how to go back and forth without losing information.

-- LisaDusseault - 13 May 2004