[jp] Synchronicity Comparison Amongst Platforms

David A. Desrosiers david.a.desrosiers at gmail.com
Tue Sep 8 14:42:15 EDT 2009

On Tue, Sep 8, 2009 at 12:25 PM, Carlo
Graziani<carlo at oddjob.uchicago.edu> wrote:
> (1)  "Pilot", as in Palm's classic platform, is dead, as is PalmOS;
> and Palm itself has changed into an utterly different company from what it
> was when it sold PDAs.  In fact, the only recognizable feature is its
> continued swinish reluctance to open its platform to FOSS developers;

Let's be careful about this. PalmOS isn't owned by Palm, they only
license it. It is still reportedly alive outside the US, but it's not
being put onto domestic smartphone handheld devices. It is used in a
lot of places in kiosks and other point-of-sale style terminals that
ACCESS, Ltd. sells.

> At the same time, the sorts of nodes to which we may wish to sync them are
> more general, including commercial resources such as Google
> Mail/Calendar/Maps, personal assets such as home A/V equipment (stereos and
> TVs are also morphing into general-purpose networked computers), MP3
> players, desktop productivity/communications machines, laptops, and
> netbooks, to say nothing of ticket kiosks, credit-card companies, coke
> machines.  In addition, many of these assets need to sync data with each
> other as well (OK, maybe not the ticket kiosks and coke machines).

Be careful about the Kool-Aid here with regard to "cloud sync".
There's a lot of misinformation and hype about what the "cloud" is,
and what it can do. Google Gmail is not running "in the cloud". Google
Calendar is not "in the cloud", and most of the services you're used
to hearing in the same sentence as "the cloud", are just web services
with a GUI on top, that tie to other services on the back end. This is
not the cloud.

> I could be wrong, but I believe this change means that the sync model needs
> to change, becoming something less client/server oriented and more
> peer-to-peer.

Herein lies the labyrinth of complexity. A lot of commercial and free
solutions are attempting to solve this, in ways that are not
functional, once you extend past a 1:1 paradigm. Once you add a second
client into the mix (say handheld and desktop, both synchronizing to a
server-based service like Google Calendar), you add a layer of
complexity that is hard to resolve, without a lot of additional logic
in the client code. If you always go from

J-Pilot -> Google Calendar
Handheld -> Google Calendar

There's no way for J-Pilot to know what was on the Handheld device,
and so the next time you sync either of those clients to the server,
you have to do a full compare of every item in a record, to make sure
there aren't changes which have to propagate to the other side. You
also need some sort of queuing and marshalling to make sure data gets
added and removed in the appropriate order, not just en-masse.

Another level of complexity is knowing what capabilities a given
device supports, BEFORE you sync the data from it. For example, my
Palm M505 didn't support photos in AddressBook records, but J-Pilot
does. If I sync J-Pilot to Google Contacts (for example), and then my
m505 to Google Contacts, what happens to the photos in the records? Do
they just get stripped out when they go to my m505, and added when
they go to J-Pilot?

The logic to handle these situations has to exist also.

In the end, we need to get out of the monolithic, pre-defined schema,
record-level-comparison mindset, and into looking at the data for what
it MEANS, not what it SAYS. This means a new device we've never seen
before, should be 100% compatible with the data stored in J-Pilot or
the server service right from the start, without having to dig in and
find out what new fields or other fields it has that we don't know
about yet.

"Oh, we call this field email_one, but it calls it
internet_address_001, we need to create a field mapping..."


We should accept everything a client sends us, store it in a unique
way, and extract out of it, what is necessary to facilitate sync to a
device with compatible data (i.e. photos to photos).

We're not there yet, because everyone is stuck in playing catch-up
with every new device, new OS revision of those new devices, and
trying to close the bugs related to mapping all of those fields in a
many-to-many sync relationship. It's HARD to get that right. Anyone
who has done it before knows this..

> That is, whatever pilot-link and friends become (or bequeath
> their legacy to), they will no longer be running just on a PC talking to a
> PDA, but rather they will be running on several devices *including on the
> smartphones*, and lending their interfaces to commercial services (or
> adopting interfaces offered by such services).

Over 5 years ago, I floated the idea of "Plumber" ("It fixes syncs!"
:), and the conversation died out shortly thereafter.


> We're each going to be supervising small networks of machines, some
> portable, some not, and those machines will all be talking to each other
> and to external services, making available data to devices where it is most
> useful, safeguarding data integrity, preventing data loss, and to the
> greatest extent possible safeguarding our privacy and data security.  We
> need tools to manage that.

Think de-centralized data-aggregation portable devices and portals.
The data is no longer "just" on the device, it can be aggregated and
cached (ala WebOS) on the device from various local and remote sources
(i.e. your hand-entered address book, as well as your Facebook friends

> Any guarantees of data privacy and application security made by FOSS developers are mooted by
> the interference of Apple's arbitrary and capricious application approval
> process.  I believe similar considerations apply to Palm's new OS, although
> I could be mistaken.

Simple solution: Communication

If you don't care about security, use their device. If you do, buy a
device that helps enforce that security (and allows the appropriate
FOSS app to leverage that level of security). If the Apple App Store
doesn't allow "Plumber/SSL" (or whatever) to exist, then we don't
support their device, unless you jailbreak it (thus voiding the
warranty, sigh). I'm of the personal opinion that you shouldn't have
to jailbreak your device, to make it secure your data or to use it how
you want to use it.

Likewise for the Palm, BlackBerry, Android, and
whatever-app-store-may-come-next. We're always going to be faced with
new devices, new vendors, new OS versions, etc. This too is another
game of catch-up. There is nothing wrong with securing your data on
your device. It should be paramount if you carry it with you.

Yes, a phone should first and foremost have stellar phone function and
capabilities, but compromising that to add a mediocre mp3 player, and
leaving your phone logs and address book and such out in the clear, in
the open, should not be an option.

> OK, that's a long message, about something I've thought about but have no
> real expertise on.  I'd be perfectly satisfied to be told off by experts
> about all the ways in which all the above is wrong or stupid or irrelevant
> or otherwise makes no sense, so long as someone ignites and sustains a real
> discussion about where we go now that our old world is dead.

Our old world isn't dead, we've just expanded it to include new
capabilities. Now we have to think about how to incorporate those into
our own workflow. My personal use of my handheld device is very
particular, and very extreme, but will soon become commonplace
(carrying multiple, simultaneous calendars on the device at the same
time, while keeping them clearly-defined and separate at the sync

I've been talking about the need for a clear solution to group
calendaring for 9+ years (search my blog for "group calendaring"), and
we still haven't moved a single inch closer to making it happen. That
is frustrating.

I'm open to having an on-list discussion on the matter, or creating a
new generalized list to talk about it at whatever high or low level we
need to. It affects us all... from J-Pilot and pilot-link to
gnome-pilot, KPilot, and most people who use handhelds to sync to
anything these days.

More information about the Jpilot mailing list