So, I’m the friend with whom the expensivelesbian was having a chat the other day…
On a Newton it was indeed vary rare for you to loose data in the case of a power failure. You wouldn’t actually end up exactly where you left of when/if you lost power (or reset) though, instead your Newt would reboot and start up the app it was configured to start. In general though you wouldn’t have lost any data - well, maybe a few words, and possibly as much as a whole sentence.
There were two factors at play here. Firstly there’s the storage model, and secondly general application design.
Newton used a persistent dynamic object oriented database system for storage, rather than a traditional filing system. The basic object in Newton OS is called a frame, which is a slightly different concept to a class, and the databases were called soups. (NewtonScript, the language you used to write Newton apps, has more in common with Self than C++.) There were a few things to be careful about when writing frames into your applications soup (or soups), but essentially you could store frames of any format into soups. There was a concept of “folders” in the storage which provided some structure, however this was implemented using standardly named slot in your stored frame. Soup storage was tightly tied to the language and object model, which made coding for it very simple.
Newton storage would either be battery backed ram, or flash memory. Both were supported. There was even rudimentary support for ATA built into late versions of Newton OS, which has since been completed by inventive third party hackers.
More important is general application design. The Newton UI paradigm was based around the notepad, rather than the desktop…
Newton apps don’t have a “File” menu (since there’s no filing system as such), and no “Save” option. After all, if you scribble something into a notepad you don’t have to “save” it. You would design your application to save its data in response to edits. If you planned on dealing with a lot of data at once it was sensible to design ways in which this data could be split up into smaller frames and stored separately in order to get better storage performance. (Newton devices had limited memory, so this kind of thing was normal practice.) Tapping the “overview” button, located between the up and down scroll arrows, would generally give you a list of all “documents” applicable to the application you were using filtered by the folder you were viewing.
Doing stuff with “documents”, such as duplicating them, printing, sending them as a fax, was done using a standard “routing” menu, signified with an envelope icon. This was actually extensible - new output methods could be added to all apps that supported standard routing options.
It is of course perfectly possible to design desktop apps in a similar manner. From what I understand Apple has done something like this in Aperture, their new high-end photo software - it doesn’t have a save option either, yet all edits are persistent.
The key is to make it easy for the developer to write applications that don’t need a “save” option. It must be trivial to regularly write out updates to persistent storage. Mac OS X 10.4’s CoreData, essentially an SQL database engine, helps Aperture do its stuff. From what I understand you guys have a bit of a head-start on that kind of thing with your storage model.
So, to summarise, this kind of behaviour in apps is essentially down to application design. The only other thing that would help a lot is a hefty chunk of sample code that simply demonstrates how to build applications that don’t have a save option.
