[jp] Categories in Datebook
David A. Desrosiers
hacker at gnu-designs.com
Wed Jan 26 15:05:14 EST 2005
> I also found that strange. Does PalmSource release their data
> format or not?
In most cases, no.
> If not, it explains why synchronizing seems so buggy,
Synchronization can be "buggy" for any of about 2-dozen
reasons. Here are the top 6:
1.) Kernels with patches (stock kernels ALWAYS work, IMHO)
2.) Flaky/misconfigured hardware (third-party USB hubs, for
3.) Misconfiguration of hotplug, devfs, udev and related
scripts, hacks, and workarounds.
4.) Conflicting software running (gnome-pilot's daemon running
while trying to synchronize with J-Pilot for example).
5.) Incompatible versions (pilot-link-cvs vs. J-Pilot 0.98)
6.) Device and OEM changes/workarounds (ahem, Sony)
> and further I would expect J-Pilot to give a disclaimer that it can
> only make guesses and can't be sure synchronization works due to
> lack of co-operation from PalmSource. If so, the phrase "reverse
> engineering" isn't true.
The problems aren't entirely Palmsource's fault. Vendor OEM
changes are also a major hurdle (Treo90/Treo300, Sony Clie models,
We do what we can, but Palm<etc> keeps changing things on us,
without warning, and without documenting those changes. For each new
device, it takes a user or developer to find the bugs. Sometimes its
after-the-fact, and sometimes not. We never know up-front, what kinds
of issues we'll face. udev and the FC3 kernel breakage was one of the
more-recent issues that are starting to affect people.
Its a lot like "whittling wood". You start with a block of
wood, and remove piece by piece, until you have something worthy of
using or looking at. Eventually, all of the "bugs" will go away
(until, of course, they change things or introduce new bugs).
No disclaimer required.
> What handheld operating systems have their synchronization
> specification available for everyone to use, i.e. of Palm, Windows
> CE, blackberry, and whatever others there are?
Well, now we're talking about synchronization specification,
and that part works (from the pilot-link -> device perspective).
Palm<etc> will never document this, and they have repeatedly confirmed
that, because its their IP, and they don't want their competitors to
gain access to it.
The data API, however, is different. Its a rapidly-moving
target, and from what I understand, the latest device API is not
documented, because it is supposed to change, and change again, before
they finally decide its solid enough to document.
> If some do and others don't, I would think it's not even worthwhile
> to try to reverse engineer the ones that don't since it's so
> difficult. At least I wouldn't be caught doing it.
Reverse-engineering is not illegal (unless you're working with
.pdf files or going against Adobe). We're doing the best we can, and I
think, given the circumstances (unfunded, no vendor support, working
in our spare time), we've done quite an outstanding job.
> I really can't think of a reason why any of these companies wouldn't
> release their data formats, though. It would just hurt themselves
> more than anyone.
One word: Patents.
David A. Desrosiers
desrod at gnu-designs.com
More information about the Jpilot