Subject: [VCARDDAV] Terminology Issues - simple device

From: "Darryl Champagne" <[email-masked]>
Date: Tue, 8 Jul 2008 21:45:19 -0400

Once again, I see major differences in terminology and goals.

In order to have a hope of a discussion that makes sense, we need to agree
on our terminology.

In previous emails I defined "Sync Anchors", "Slow Sync", "Object Level
Duplicate Detection", "Field Level Duplicate Detection", and "Sync
Meta-Information".

In this message, I want to define device capabilities, and some related
requirements.

What I have been referring to as a simple device, can best be described as a
"low-end consumer phone".  Essentially, the type of phone you get for free
(in the US), because of the operator subsidy for signing up for a plan.

In today's world (which isn't exactly what we are talking about regarding
vCard 4.0 support - I am assuming some progress), these devices are capable
of receiving a vCard in their sync client (usually vCard 2.1, although some
are starting to support 3.0), and storing the fields that they care about
into their native data storage format.  All other fields are tossed.

The Sync Client is responsible for detecting which vCards have changed since
the last sync (which requires support from the contact manager), and
tracking a persistent identifier for each vCard (part of the Sync
Meta-Information).  In the worst case, these identifiers are as simple as
Contact 1 through Contact X, but they generally are short strings - e.g. max
8 characters - definitely not UIDs.

The general term for the data that tracks what has changed since the last
sync is a "Change Log".

Low-end consumer phones may be thought of as having two basic types of
change logs available.  The simplest, that fortunately is getting rarer, is
to just have a single "dirty" bit/flag per contact.  If this is all that is
available, the sync client may have to do extra work to detect deletions
since the last sync - such as by keeping the list of previous identifiers,
comparing it with the current set, and extracting deletes from the
difference (or it might have the information kept for it).

More common is something closer to support for the REV property - though
usually not as exactly that.  For example, the contact manager may build an
ordered list of all the record identifiers that have changed.  If one is
lucky, this might actually be REV information (which helps greatly when
syncing with multiple servers), or else it may just be a list that you clear
out after a successful sync.

Generally, there is no capability at all to identify which fields of a
contact have changed - the data must be handed off to a more powerful
machine to figure that out.

Some related issues:
- On some/many of these devices, the mapping of Sync Identifiers to actual
contacts is stored only in the Sync Client's data.
- On some of these devices, the change log is stored separately from the
contact database.

A typical use case for Sync with these devices is a backup and restore
capability (e.g. Verizon Wireless provides a Backup Assistant for most low
end phones - last I knew it was a FusionOne SyncML app).  Another use case
is to sync with your PC.

However, if I want to do both - have some phones backup to the Verizon
portal, and also sync with my PC, I usually have to have two separate sync
clients on the device.

Besides the obvious waste, this has a major problem - all Sync Client data
is independent.  Frequently, if I sync with one client, the change log is
wiped out, and the next sync with the other client will have to be a slow
sync.

As a related problem, even if I am just using a single sync client, these
devices sync software is not known for being especially robust.  When using
the built-in sync client, there are bugs known to lock the phone hard enough
that you have to pull the battery to get it back, do a complete device
reset, or just lose all Sync Meta-Information.  When using downloaded
software, you experience a problem when users re-download the software,
download a new version, or do various kinds of reset and reload operations,
which also lose the Sync Meta-Information.  Recovering from any of these
requires a Slow Sync.  I certainly wish these were not needed, but
real-world data keeps showing that they keep happening.

While I would love to just say these are buggy clients, their loss - I am
unable to just casually write off all low end Nokia, or low end Motorola
phones (etc.).

Now, this does not mean that this is the lowest common denominator, so that
is the level of device we plan for.  However, what it does mean is that I
cannot exhibit catastrophic failures when one of these devices does end up
doing a slow sync.  In the Sync World, catastrophic failure would generally
be considered duplicating your address book or various fields within each
contact (or wiping out your address book).

Now, as time progresses, these clients are steadily getting more powerful,
and want to sync more data (like the new photos they take).  My hope is that
we can start supporting PIDs, REV, and hopefully UIDs in these devices.
However, this data is unlikely to go into the core address book application,
but rather still be contained within the Sync application.  Thus the issues
with multiple sync clients, and occasional loss of Sync Meta-Information can
reasonable be expected to continue, and thus occasional slow syncs are still
to be expected, which would probably not preserve PID information, and
probably lose change log information.

Next, what can higher end devices support?

Thanks,
dgc
--
Darryl G. Champagne
Technology Evangelist
Funambol
AIM/Y!/Skype: dgc03052
ph: +1 (603) 424-0323     Mob: +1 (603) 440-3621 (+ SMS)
[email-masked]          http://www.funambol.com 

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav