[Pythonmac-SIG] Python Palm hotsync software?

[Rob Tillotson]

Wayne Folta <wfolta at netmail.to> writes:

> Anyone out there experienced with how Palm hotsync works? With Palm
> abandoning it's Mac Palm Desktop software, we really need a sync
> solution. I imagine Apple might fill the void, but based on iSync so
> far, I'm not confident it will be a palatable solution.


I have some experience in this area... back in 1999 or so, I had a
project called Pyrite, which was aimed at being a python-based Palm
sync manager.  By the time I abandoned it in early 2000, it had a
conoduit framework (using pilot-link for communication), backup and
install conduits, and a lot of the infrastructure needed to sync the
builtin apps.  I gave up because I was spending too much time building
infrastructure unrelated to Palm stuff, and getting bogged
down... anyway, here are my thoughts on the current situation:

The problem with Palm not supporting the Mac goes deeper than just
having a desktop interface.  The problem is that if Palm doesn't
provide at least the HotSync portion of Palm Desktop, *nothing* can
talk to the palmtop, not even iSync.  It seems highly likely that Palm
will be changing the HotSync protocol for Cobalt, especially
considering that there have already been changes which render the
current Mac HotSync library incapable of talking to some *current*
models that run OS5.  The problem has, in effect, already started.

So, at the bare minimum, communication must be possible.  We can only
hope that pilot-link manages to become Cobalt-compatible at some
point, which would take care of all the low-level stuff on the wire.
Pilot-link is portable Unixy code; it works fine on OSX and its
library can easily be wrapped in Python (I did a SWIG based wrapper
for it long ago).

The next issue is the conduit API.  Somehow, the sync system has to
allow third party conduits to hook into it... and if that is going to
work in practice, there has to be exactly one conduit API for third
party developers to use.  It will be hard enough to convince third
parties to support the Mac now that Palm is officially dropping
support, but if the replacement for the Palm HotSync manager does not
carry the authority of being THE conduit API for Palms and OSX,
getting third party support will be close to impossible instead of
merely very hard.  Ideally, it should not only be the only reasonable
choice available, but it should also be endorsed by Apple and/or some
existing developers, even if it is only a de facto endorsement like
making iSync work with it.

Given the need for standardization, I think the best way to go,
development-wise, is Objective-C with as much Cocoa-friendliness as
possible, conduits as loadable bundles, etc.  (The Palm stuff
currently is, I believe, a Carbon app with a C++-based API.  If we
have to reinvent it all, I see no reason not to do it the Cocoa way.)
Python would be an excellent language to implement the actual conduits
in, though, given an Objective-C framework to work in.

Unfortunately, I'm not very optimistic about any of this right now.
People have been working on Palm syncing stuff for Unix for years now
and there are still a plethora of different conduit/desktop systems
out there.  There is basically no third party support, and I think a
big part of the reason for that is the lack of a single target for
developers.  Now, the Mac is being dumped into the same boat... I hope
that someone can step in with something that will be worthy of use on
OSX.  (Ideally, I'd like to see Apple do it.)

Anyway, I'm currently too annoyed with Palm to even consider working
on something like this, but since I have done some of it before I'd be
happy to discuss my experiences with anyone trying to start such a
project...

--Rob

-- 
Rob Tillotson  N9MTB  <rob at pyrite.org>