Questions about Orthogonal Persistence

[Francois-Rene Rideau]

Dear Itamar,
   I redirected my answer to your private mail into the os-ideas@tunes.org
mailing list, where I think it is relevant.

On Mon, Dec 20, 1999 at 10:29:52PM +0200, shema1@inter.net.il wrote:
> First of all, let me tell you that I find the TUNES glossary very 
> interesting and thought-provoking.
Thanks a lot.

> However, I do have a difficulty 
> understanding your view about orthogonal persistence, so I will try 
> to describe the issues I do not understand. Please excuse me for 
> any mistakes, as everything here stands to my understanding only, 
> and it is a new concept to me.
That's ok.

> Can orthogonal persistence be implemented efficiently on a single 
> computer system?
It can, and it has been in the past (see at least Eumel).

> Let's take a single computer system, with a 
> single user writing a document. Now, if I understand correctly, the 
> system would automatically write the data to the disk. But, it won't 
> do it everytime the user is, say, typing a character, I assume - the
> disk will not be written to non-stop, would it?
There would be buffering, indeed. Many people have suggested that
battery-backed up buffers (TRAM -- transactional RAM) be used
to allow for both safe and efficient operation. Unhappily such things
are not available, and we're forced to compromise otherwise.
The compromise is that either you use somewhat uninterrupted
power supply (UPS) for your whole system (rather than just the TRAM),
and/or you allow for some latency before buffers are committed to disk.

> So, in case of a power failure, or if the user hasn't got the option of
> saving his document and he just turned the computer power off, the
> user will have the lastest copy of the document that his system
> had saved for him, and it may not be the latest copy. Obviously, 
> something is missing here - can you please explain?
The user may control the latency of committing, in a document-dependent way;
and he may also insert explicit synchronization and wait for disk commits
(just like fsync() under Unix).

> Plus, one of the advantages people attribute to working on
> documents with a computer, is that you can make as many
> changes as you like without making copies and save only when 
> your satisfied.
Indeed, even with orthogonal persistence, users will want some
kind of explicit save/commit primitive to distinguish
between well-established releases of his documents (see CVS).
Just because you do not have to explicitly save and load data,
with tedious marshalling and error management, doesn't mean you
have nothing to do.

> Orthogonal persistence will diminish that advantage, 
> and if someone would want to gain that advantage back, it would 
> be more complex to implement than on a normal file system.
Orthogonal persistence will change nothing about the advantages and
intrinsic complexities of project management; what it will do is provide
enhanced reliability through simpler and better factorized implementation,
with system-side marshalling and error management.

> Finally, files aren't just a low-level abstraction - they do have their
> own counterparts in real life, and even in a system that implements
> orthogonal persistence there is place for files and folders; they're
> not contradictions, to my understanding.
There is definitely a place for "dictionaries" that bind objects
to human-readable and typable names. But these objects are not "files",
in that they are not defined by a low-level stream of contiguous bytes.

> All this is not to say traditional file systems are perfect; far from it. 
> But I'm just not sure about some aspects of orthogonal persistence.
I hope I helped clear the case.

> Anyway, thank you for your time.
> Itamar
Thanks a lot for your useful remarks.
Indeed, such explanations ought to be included in the Glossary.

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Knowing the Path is not the same as Taking it.
	-- The Matrix