[jp] Categories in Datebook

Adam Richard g4c9z at unb.ca
Wed Jan 26 19:01:42 EST 2005

Quoting "David A. Desrosiers" <hacker at gnu-designs.com>:

> > 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)

It's not an opinion, and I doubt they do.  Surely a bug was found in the Linux kernel at
some point.

> 	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)

None of these are true synchronization bugs.  So are you saying you believe the
synchronization algorithm used by J-Pilot isn't buggy?

> > 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. 

I think a disclaimer is required whenever you have to guess at something, in other words
whenever you have no way of verifying whether your software works.

> > 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.

So now you're saying there is an API.  That's what I meant by "do they release their
data format".  It is always, from what I can see, in their best interest to release
information to interface with their data.  It is not necessarily in their interest to
release their implementation details, and it's understandable if they don't.  I was
asking whether they release the interface (also called API).

> > 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.

Of course I didn't mean it's illegal or unethical, I just meant reverse engineering (the
proper sense of the term) is so difficult that I'd never waste time doing it.

> > 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. 

What did they patent?  The interface or the implementation details?  I can't see why
anyone would want to prevent people from knowing the former.

More information about the Jpilot mailing list