Roy Schestowitz wrote:
__/ [ Jamie Hart ] on Wednesday 03 January 2007 15:03 \__
The specification for PalmDoc is available all over the internet and
there is no licensing restrictions on using it.
Please, don't confuse "unknown to you" with proprietary.
Yes, you are right on this one. At the time (when I worried about lockin), I
only complained about/moped over the form of the files, but I found HTML
convertors and some extensive documentation of the binary bits in the PDB
files. I just wish it was something like XML, but I'm aware of the cost of
parsing that on a mobile device.
XML has the added problem of storage, on a device that originally had
1meg of storage a format such as XML would have been prohibitive. what
was needed was a compressed format that didn't need additional scratch
space during decompression (remember the Palm devices run applications
in place, i.e. there is only one piece of memory available which is used
both for storage and execution of programs). PalmDoc was the first
format devised that did the job.
Only recently I managed to export
everything to KOrganizer. From there, I could export as i/vCal and put it
on a Web-based PHP Calendar. At least I now know that I could live without
Palm's proprietary blobs which interpret the data. Roy Ingles also gave me
a pointer to a pilot-link tool which converts things to plain text...
There are a plethora of software out there that can convert to and from
palm doc format.
I'm writing a program at the moment for my new GP2X that will include
reading and writing PDB files. I've had my address book on my Sony Clie
for years and want a similar program on the GP2X. Currently there's
nothing available, so I'm writing one.
Sounds excellent. If this ever leads to good PIM on the GP2X, I'd probably
switch. I was hoping for something as such for the Nokia 770, but every time
I research this I find nothing. The last time I checked there was a buggy
GTK application being developed and used by a few.
Be aware that a good PIM on the GP2X is not likely to get off the
ground, the lack of any text entry facility (other than on-screen
keyboard) seriously hinders the platform in this regard. The program
I'm writing will primarily be a viewer for existing address book
entries. I'll include the ability to add new entries, but I don't
expect to use it much, and I doubt anyone else would want to either.
I had the option of converting my existing addresses to either text or
vCal formats, but in the end decided to keep them in the palmdoc PDB
file. It also means that I can reuse parts of this program in my second
project, an e-book reader for the GP2x that will handle PDB files.
I am relieved to hear that these PDB's are not as evil as I thought... in the
sense that there are enough tools out there which handle them.
It's an open format, which means there is documentation all over the net.
Well, archives are another matter. They are probably useless, but in many
case they remain barely accessible. In the case of Palm, it's a mismash of
binary and ASCII.
No, no, no. It is not a mismash, it is a compressed format designed to
run on a machine with very few resources. it does an admirable job in
very few CPU cycles.
It does scale well, I'll admit. Loading a day on the diary takes less than
half a second, even with a ~300KB PDB (IIRC).
Also remember there has been a huge jump in processor power since the
machines that PalmDoc was designed for. It had to work almost that fast
on devices with a tenth of the processing power yours (probably) has.
Not a nice way to have your diary saved...
But hardly a problem for anyone with a little google-fu.
Both the Windows based Palm Desktop software supplied by Palm and the
Linux based KPilot software allow you to view the contents of these
files and to export them to plain ascii files if you so wish.
Yes, that's true. Bear in mind, however, that it's not trivial taking data
from Palm Desktop or KPilot over to another device. I don't think it's a
simple case of dump (export), then load (import). I'm not sure there are
standard formats either. Someone told me that vCal iCal are not standard (is
it just Apple?)...
A lot will depend on the device, both Palm Desktop and KPilot will
export to CSV files and you can't get much more standard than that. I
would suspect that most devices or the desktop software associated with
them would handle CSV data.
The problem arises in the fact that the fields used by the palm
applications will be different to the ones used by a different device.
The data will need to be massaged to fit whatever layout the new device
expects. But that is not a format problem, it's a data problem and a
common one when passing data between applications.
|
|
