(Thanks, jem, for the reminder about the original problem.)
Quote:
|
Originally Posted by ueila
I tried to backup the .ofocus files to a Thecus N4100 NAS server on my network but found it was not possible and kept getting an error message about file length.
|
What software are you using to make the backup? That doesn't look like a message the Finder would produce (it used slashes for the path separator while the Finder generally uses colons), so I'm assuming some other tool is involved?
Quote:
|
Originally Posted by BwanaZulia
I would actually be interested in more information.
|
Anything in particular you're curious about?
One obvious curiosity that comes to mind is: why are we writing our XML as separate transactions rather than in one big file the way we usually do (in OmniGraffle, OmniOutliner, and OmniPlan)?
Well, I talked a bit about the advantages of XML, but I left out a big disadvantage: they're not very efficient to read or update. To read an XML document, you have to read the entire contents of the file (and there's no easy way to skip parts you aren't interested in). To update them, you have to rewrite the entire contents of the file. A big advantage to SQL is that you can read using a query which gives you just the results you're interested in, and you can do an update which touches only the records you've changed without rewriting everything else.
But another downside to SQL (besides the extensibility problem) is that even though you can write a single record quickly and efficiently, an incremental backup (such as the backups Time Machine will make in Leopard) has to make a complete copy of your entire database even if you only changed one record.
We wanted OmniFocus to be able to read and update your data quickly, so that we'd have fast launch times and fast save times—particularly because (unlike our other applications) we wanted to automatically and immediately save every edit. This suggests we should use SQL. But we also wanted our data format to be extensible and efficient to back up, which suggests we use XML.
So we built a hybrid system which uses a SQL database to handle the reads and updates efficiently, while recording each database operation as an XML transaction for extensibility and efficient incremental backups (the backup system only has to record the new transactions, not the entire database).