I can certainly imagine a non-persistent world -- why do you keep saying that I cannot?
It is called "restaurant". You come in and get a clean, fresh table. You sit on it and eat, and if you have leftovers, you put them in special boxes. When you leave, everything on the table that you did not put in a box disappears. Very nice and handy!
=====
So what happens in case of errors?
os ->(repaint)->window->(get state of)->document->(EXCEPTION: LIST INDEX OUT OF RANGE)
Word->Open file->Error reading file: LIST INDEX OUT OF RANGE
Does this?
Your point is obvious, but not specific to persistent environment. Things are getting broken sometimes.
Actually, back in 2009 when first message about Phantom appeared, I've got a message from team in Stanford. THey did an experiment about things we discuss.
Relatively big Java program was stopped in the middle of work, serialized to (I believe) XML and some objects were removed from that XML. After that program state was de-serialized and program continued to run.
Experiments shown that modern code degrades quite gracefully in such cases. Most of time problems were not global and affected just parts of program's abilities.
But again, it is not a persistent world specific problem.
If your code is wrong, no matter where index lies - in persistent memory object or in file. Index will be wrong.
The question is how system must be built, what kinds of services it must provide to limit app ability to shoot itself in a foot. That is one of the goals of this project.
In Word (especially when save-in-place disabled), old file disappears only when the new file is complete. And since file writing naturally walks over all the structures, any exceptions usually happen during save and display time.
If the file ended up on disk, it is usually OK.
And even if you are unlucky, you can still restore it from your backup (time machine, dropbox folder, restore point, etc..)
If you have explicit "save" action, all of those things happen automatically -- there is no need for programmer to do any sort of action here, other than to make sure saves are atomic.
Only persistent environments have this problem, because once your persistent-word crashes, you cannot do anything to roll back the change -- other than revert entire OS to previous snapshot, but this will roll back all other apps, too.
(Practically, I've had MS Word crash on me hundreds of times. I've only got corrupted save file once or twice. So at least from my anecdotal evidence switching to "persistent world" would make data loss much more frequent.)
Returning to restaurant: you just went off a problem. In your case restaurant is persistent. And a road to your home exists. Suppose, home exists too and you do not rebuild it returning from the dinner.
And at the moment when Linux boots, all the world is absent and is built again from files.
(There's not just no spoon - there's no restaurant. :) And no white rabbit. :)
My home is persistent, and this means I have to clean it up and repair it. I would like to have a magic "reboot" button, which restores my home to blueprints and discards everything not stored in cabinets, drawers and containers.
Ants infestation? "reboot". Walls need painting? "reboot" Don't want to wash the dishes? "reboot"
Isn't this cool? And the best part, we have this for PC already -- and we use it a lot. I can see why one would want to have a small part of the system persistent, but the the entire system? This does not seem useful.
Comments
I can certainly imagine a non-persistent world -- why do you keep saying that I cannot? It is called "restaurant". You come in and get a clean, fresh table. You sit on it and eat, and if you have leftovers, you put them in special boxes. When you leave, everything on the table that you did not put in a box disappears. Very nice and handy!
=====
So what happens in case of errors?
os ->(repaint)->window->(get state of)->document->(EXCEPTION: LIST INDEX OUT OF RANGE)
Does this result in losing the document forever?
Word->Open file->Error reading file: LIST INDEX OUT OF RANGE
Does this?
Your point is obvious, but not specific to persistent environment. Things are getting broken sometimes.
Actually, back in 2009 when first message about Phantom appeared, I've got a message from team in Stanford. THey did an experiment about things we discuss.
Relatively big Java program was stopped in the middle of work, serialized to (I believe) XML and some objects were removed from that XML. After that program state was de-serialized and program continued to run.
Experiments shown that modern code degrades quite gracefully in such cases. Most of time problems were not global and affected just parts of program's abilities.
But again, it is not a persistent world specific problem.
If your code is wrong, no matter where index lies - in persistent memory object or in file. Index will be wrong.
The question is how system must be built, what kinds of services it must provide to limit app ability to shoot itself in a foot. That is one of the goals of this project.
In Word (especially when save-in-place disabled), old file disappears only when the new file is complete. And since file writing naturally walks over all the structures, any exceptions usually happen during save and display time. If the file ended up on disk, it is usually OK.
And even if you are unlucky, you can still restore it from your backup (time machine, dropbox folder, restore point, etc..)
If you have explicit "save" action, all of those things happen automatically -- there is no need for programmer to do any sort of action here, other than to make sure saves are atomic.
Only persistent environments have this problem, because once your persistent-word crashes, you cannot do anything to roll back the change -- other than revert entire OS to previous snapshot, but this will roll back all other apps, too.
(Practically, I've had MS Word crash on me hundreds of times. I've only got corrupted save file once or twice. So at least from my anecdotal evidence switching to "persistent world" would make data loss much more frequent.)
Returning to restaurant: you just went off a problem. In your case restaurant is persistent. And a road to your home exists. Suppose, home exists too and you do not rebuild it returning from the dinner.
And at the moment when Linux boots, all the world is absent and is built again from files.
(There's not just no spoon - there's no restaurant. :) And no white rabbit. :)
My home is persistent, and this means I have to clean it up and repair it. I would like to have a magic "reboot" button, which restores my home to blueprints and discards everything not stored in cabinets, drawers and containers.
Ants infestation? "reboot". Walls need painting? "reboot" Don't want to wash the dishes? "reboot"
Isn't this cool? And the best part, we have this for PC already -- and we use it a lot. I can see why one would want to have a small part of the system persistent, but the the entire system? This does not seem useful.