Rui CarmoThis post is part of my Data For The Ages Category, where I outline my strategy for making sure the data I use has some guarantee of surviving my current platform.
Some people will have noticed that VoodooPad has a new file format, based on a data bundle (i.e., each VoodooPad document is now a folder with an internal database, instead of a single XML document):
Untitled.vpdoc --+-- sk.index (probably a keyword index for Spotlight)
|
+-- store.vpsqlite (the SQLite database, with inter-page
| linking, modification dates, document-specific settings,
| UUID-to-page name mappings, etc.)
|
+-- pages (a sub-folder containing all the pages in serialized
RTFD format, with UUIDs for filenames)
Since I use the Lite version this is kind of a side-step for me (not forward, not backwards, just different and noteworthy). Although it is somewhat of an improvement over the old encoded-RTF-in-XML format, it still has a few issues where it regards portability.
And yes, yes, I know that the full versions will export to RTF and HTML. That is not the point - I have no need whatsoever for the extra features, I just like to know how I can get my data back if I decide to move away from VoodooPad, or even the Mac.
Data Extraction
Since the files in pages are RTF-based, I can convert them manually to other formats using unrtf, rtfdtohtml and a few other options (there are plenty of Mac OS X tools to deal with RTF, but I'm sticking to UNIX tools because I know those will be usable on any platform).
Counter-intuitively, just renaming the UUID-named files to .rtfd and trying TextEdit doesn't work, but that's just because they are serialized Cocoa rich text data. You see, the real .rtfd format is also a data bundle - a folder containing a TXT.rtf file and associated images, with the images being referenced via the \NeXTGraphic primitive inside the RTF file.
But at least theoretically it should be possible to grab the SQLite file, iterate through the page table and convert everything to HTML with a Python script, which is reassuring.
.Mac Shenanigans
The real hassle with the new format comes when you try to store a .vpdoc file in .Mac's iDisk and share it between a couple of Macs. In the old format, editing a page changed the whole XML file, which was then uploaded (whole) to my iDisk. Easy to sync, nasty for very large documents.
Now, editing a page changes the file under pages, the Spotlight index and (occasionally) the SQLite database - especially if you add new links or do something that changes the document preferences. Much better for very large documents, but trickier to sync.
Now, what do you think happens if you add a new page and, for some reason, .Mac fails to sync your iDisk properly? Or if there are conflicts like this one:
Disaster waiting to happen
Oh yeah, data loss. If the SQLite database gets synced correctly, your page is listed on VoodooPad but is empty. If the page itself is synced correctly but the database isn't, the RTFD page is there but the database doesn't know the first thing about it.
Gus isn't to blame for this (Apple's slow-as-molasses iDisk is), but I've now got both kinds of data loss on my "Home Pad", so beware - you should be fine (and enjoy a massive performance increase) if you use VoodooPad locally or through LAN file sharing, but using it on your iDisk isn't recommended - again, solely due to Apple's faults.
I will be posting more regarding .Mac in the future, and why my ISP connection isn't to blame for the slowness (hint: I've got more than one Internet connection, and work in the business).
Colophon
Regarding VoodooPad's new data format, I'd give it 4 out of 5 regarding balancing Mac-specific features and portability - i.e., it's easy enough to recover most of my data (in the sense that I can either upgrade to a version that exports it or roll my own exporter), and it leverages Mac OS X's built-in features in a sensible way.
However, no amount of cleverness can protect you from poor storage, so make sure your iDisk is properly synced before trying to use a VoodooPad document on it.