[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 
	    eexample)
	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, 
etc.) 

	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
http://gnu-designs.com



More information about the Jpilot mailing list