Roger Binns
2004-05-14 22:23:15 UTC
(I spotted even more grammar mistakes in previous mail - please indulge
me as I was very tired at the time :-)
Anyway, I didn't mention what is actually hard or different about cell
phone syncing. There are two things - losing information and information
degradation.
Losing information or meaning
=============================
The PIM you sync with needs to be able to contain a superset of all
information otherwise the sync will lose information. For example, if
it doesn't know anything about speed dials, then syncing with a PIM
will tend to lose your speed dials. This leads to people being reluctant
to sync and the phone becoming an island of accurate information.
It can get quite a bit more complicated. For example the LG phones
store 5 phone numbers and the order matters. Many PIMs don't care
about the order of phone numbers. That means that sending the numbers
back out from the PIM can scramble the numbers in the phone.
Sometimes you have to do mappings and be very careful with them. For
example the Palm Desktop has a phone number type of 'main' and the
Sanyo phones have a phone number type of 'data'. No other PIM to my
knowledge has the 'main' number type (including BitPim) and BitPim
appears to be the only one that has 'data'. The syncs often translate
the information into another type - for example they may take the
'main' number from Palm, and turn it into 'office' and store it that
way. Of course when you sync back with Palm, they have lost the information
that the number was actually type 'main', and write it back into the
'office' field in Palm. There may already be a different 'office'
field, so they end up putting it in 'office2'. Before you know it,
you will find each entry has several phone numbers duplicated, and
every time you sync it gets worse. (This actually happened with me
using TrueSync several years ago).
Sometimes they don't provide enough granularity. On the LG phones you
can have two different ringtones for a person - one for when they
call and one for when they send a text message. If the UI in the
PIM only allows setting one, then again information is lost.
The design of Chandler (and sometimes other PIMs) is to allow arbitrary
extra information to be stored alongside each entry. This partly solves
the problem (for example you could store the extra phone number labelled
'data') but the user interface and other plugins are not going to know about
the extra information, its uses or its semantics.
And sometimes PIMs just have arbitrary limits - neither Outlook nor
Evolution will let you store more than two work phone numbers for someone.
Palm won't let you have more than a total of 5 phone numbers and email
addresses (though all five could be work phone numbers).
All this tells us is that many times the information stored and semantics
available in a PIM can be worse than the phone does, which makes people
reluctant to let their cell phone originated data near the PIMs.
Information degradation
=======================
This is the flip side of the coin. The phone can be worse than the PIMs.
As a simple example, many of the PIMs can store names in UNICODE (ie
most characters used on the planet). Well, our phones can do ASCII.
They may do some of the Spanish letters such as ñ but they certainly
won't do more complicated stuff (currency symbols, accented characters,
CJK symbols, punctuation). So if the original record is "mañana",
then the phone may ultimately end up containing "mañana", "manana" or
"maana".
Why does this matter? It matters when you are syncing. The sync software
has to produce a list of changes that you made on the phone. For example
it needs to work out that you changed a phone number or a name. So
if the original data is "mañana" and the phone now says "maana", is that
because of information degradation, or because the user editted the value.
It matters in the phone number fields as well. If one of the two 'home'
numbers has gone, is that because of how many 'home' numbers the phone
or other sync software can store, or because the user deleted one?
The pictureid associated with an entry will definitely be different.
It may be a low resolution version of the original, or it could be
changed. Which?
The phone sometimes even has originals and degraded versions at the
same time. The Sanyo phones and the Audiovox CDM8900 make low resolution
thumbnials of camera pictures. Sync software has to figure out if
this happened and get the high resolution original from the phone
and figure out if the user made a change or if it is just the original
information the PIM stores.
Conclusion
==========
It is fairly obvious that it is impossible to do a perfect job. Conversions
in either direction will end up losing information and meaning, and there
may also be information degradation that is impossible to differentiate
from the user editting information.
But just because it isn't possible to do a perfect job, doesn't mean we
can't try and get close. That is what BitPim will be doing. It is going
to require some smart thinking, smart testing, good feedback, and trial
and error.
Roger
me as I was very tired at the time :-)
Anyway, I didn't mention what is actually hard or different about cell
phone syncing. There are two things - losing information and information
degradation.
Losing information or meaning
=============================
The PIM you sync with needs to be able to contain a superset of all
information otherwise the sync will lose information. For example, if
it doesn't know anything about speed dials, then syncing with a PIM
will tend to lose your speed dials. This leads to people being reluctant
to sync and the phone becoming an island of accurate information.
It can get quite a bit more complicated. For example the LG phones
store 5 phone numbers and the order matters. Many PIMs don't care
about the order of phone numbers. That means that sending the numbers
back out from the PIM can scramble the numbers in the phone.
Sometimes you have to do mappings and be very careful with them. For
example the Palm Desktop has a phone number type of 'main' and the
Sanyo phones have a phone number type of 'data'. No other PIM to my
knowledge has the 'main' number type (including BitPim) and BitPim
appears to be the only one that has 'data'. The syncs often translate
the information into another type - for example they may take the
'main' number from Palm, and turn it into 'office' and store it that
way. Of course when you sync back with Palm, they have lost the information
that the number was actually type 'main', and write it back into the
'office' field in Palm. There may already be a different 'office'
field, so they end up putting it in 'office2'. Before you know it,
you will find each entry has several phone numbers duplicated, and
every time you sync it gets worse. (This actually happened with me
using TrueSync several years ago).
Sometimes they don't provide enough granularity. On the LG phones you
can have two different ringtones for a person - one for when they
call and one for when they send a text message. If the UI in the
PIM only allows setting one, then again information is lost.
The design of Chandler (and sometimes other PIMs) is to allow arbitrary
extra information to be stored alongside each entry. This partly solves
the problem (for example you could store the extra phone number labelled
'data') but the user interface and other plugins are not going to know about
the extra information, its uses or its semantics.
And sometimes PIMs just have arbitrary limits - neither Outlook nor
Evolution will let you store more than two work phone numbers for someone.
Palm won't let you have more than a total of 5 phone numbers and email
addresses (though all five could be work phone numbers).
All this tells us is that many times the information stored and semantics
available in a PIM can be worse than the phone does, which makes people
reluctant to let their cell phone originated data near the PIMs.
Information degradation
=======================
This is the flip side of the coin. The phone can be worse than the PIMs.
As a simple example, many of the PIMs can store names in UNICODE (ie
most characters used on the planet). Well, our phones can do ASCII.
They may do some of the Spanish letters such as ñ but they certainly
won't do more complicated stuff (currency symbols, accented characters,
CJK symbols, punctuation). So if the original record is "mañana",
then the phone may ultimately end up containing "mañana", "manana" or
"maana".
Why does this matter? It matters when you are syncing. The sync software
has to produce a list of changes that you made on the phone. For example
it needs to work out that you changed a phone number or a name. So
if the original data is "mañana" and the phone now says "maana", is that
because of information degradation, or because the user editted the value.
It matters in the phone number fields as well. If one of the two 'home'
numbers has gone, is that because of how many 'home' numbers the phone
or other sync software can store, or because the user deleted one?
The pictureid associated with an entry will definitely be different.
It may be a low resolution version of the original, or it could be
changed. Which?
The phone sometimes even has originals and degraded versions at the
same time. The Sanyo phones and the Audiovox CDM8900 make low resolution
thumbnials of camera pictures. Sync software has to figure out if
this happened and get the high resolution original from the phone
and figure out if the user made a change or if it is just the original
information the PIM stores.
Conclusion
==========
It is fairly obvious that it is impossible to do a perfect job. Conversions
in either direction will end up losing information and meaning, and there
may also be information degradation that is impossible to differentiate
from the user editting information.
But just because it isn't possible to do a perfect job, doesn't mean we
can't try and get close. That is what BitPim will be doing. It is going
to require some smart thinking, smart testing, good feedback, and trial
and error.
Roger