[VM] The "Google docs" paradigm

[Uday Reddy]

A major shift in computer technology over the last 20 years or so is the
simplification of user interfaces allowing more people can use the systems
in an easier way. Unfortunately, some simplifications come at a price. The
older methods might have had flexibility or reliability that the newer
methods lose.

One of the shifts that is occurring at present is what I call the "Google
docs" paradigm, which says that you don't need a 'Save' button. A variety
of other tools are coming on the scene too, like dropbox etc., which do
automatic synchronization between clients and servers.

As emacsers, most of us probably believe in a 'Save' button. It allows us
to load a file or mail folder into an Emacs buffer, work with it, and save
it only when we are confident that all the changes need to be made
permanent.

Well, what if you forget to hit the 'Save' button? Or, your system crashes?
Or, you run out of battery? Or you had to shut things down to go and catch
a train (or an airplane)? Emacs introduced an autosave facility to mitigate
against that. However, Emacs was designed when people mostly used single
servers, typically from single clients. We are now a lot more networked.
So, having lots of copies of the same file/folder in different places with
slightly different states adds considerable complexity. Newer generations
of users that are brought up on 'Google docs' will tend to think we are
dinosaurs.

So, the question is, should we minize the use of the 'Save' button? Or, at
least provide a way to do automatic synchronization between clients and
servers?

Cheers,
Uday

[Kurt Hackenberg]

However, Emacs was designed when people mostly used single servers,
typically from single clients. We are now a lot more networked. So,
having lots of copies of the same file/folder in different places
with slightly different states adds considerable complexity. Newer
generations of users that are brought up on 'Google docs' will tend
to think we are dinosaurs.
So, the question is, should we minize the use of the 'Save' button? Or, at
least provide a way to do automatic synchronization between clients and
servers?

Emacs was designed when there was almost no networking, and no live
filesharing like NFS at all. Edited files were on local disks.

Emacs assumes there is no concurrent editing -- that only one Emacs at
a time edits a given file. There are checks to notice and warn you
about concurrent editing, but no attempt to make it work.

VM followed that model -- no concurrent visiting of a given folder --
and should continue to, IMHO, for local folders. (Or apparently
local, like NFS.) Partly because VM works by editing the whole mbox
file, and would have to be redesigned to work any other way.

But you're talking about VM being an IMAP client, aren't you? And
assuming that other clients on other computers are modifying the IMAP
folder concurrently.

I don't have much opinion, but sort of like the idea of things
happening immediately. IMAP can do that, and sort of looks like it's
meant to. How do other IMAP clients do it?

I think it's acceptable for VM to have that difference in timing
between IMAP folders and local folders. VM users are knowledgeable
enough not to be confused by that. (Emacs is a programmer's editor,
and VM strikes me as a programmer's mail reader. I expect that
everybody who uses either program is technically knowledgeable. The
general public doesn't know that Emacs and VM exist, much less use
them, and never will.)
--

[Uday Reddy]

Post by Kurt Hackenberg
VM followed that model -- no concurrent visiting of a given folder --
and should continue to, IMHO, for local folders. (Or apparently
local, like NFS.) Partly because VM works by editing the whole mbox
file, and would have to be redesigned to work any other way.
But you're talking about VM being an IMAP client, aren't you? And
assuming that other clients on other computers are modifying the IMAP
folder concurrently.

Indeed, I am talking about IMAP folders. For local folders, there is no
possibility of concurrent usage (not unless file systems start understanding
email). The No. 1 reason for switching to IMAP is to get concurrent access.
The IMAP server is in a sense a "file system that understands email".

Post by Kurt Hackenberg
I don't have much opinion, but sort of like the idea of things
happening immediately. IMAP can do that, and sort of looks like it's
meant to. How do other IMAP clients do it?

It would be possible to add a timer task that wakes up every N seconds and
synchronizes the VM folder with the IMAP server. That is how, I think,
Thunderbird and perhaps other clients do it. They don't have a "SAVE"
button.

To be consistent, we also need to update the cache folder on disk when we
update the IMAP server.

The main problem with providing such a function is that it is at odds with
the Emacs philosophy. Long-time Emacs users are used to the idea that they
can make changes to buffers inside Emacs and discard the changes if things
go wrong. In VM, I often end up expunging a folder and then realizing that
I shouldn't have. Then I can reload the folder and return to the version on
the disk or the server. If the changes get saved asynchronously without my
control, I would lose that ability to discard.

Post by Kurt Hackenberg
I think it's acceptable for VM to have that difference in timing
between IMAP folders and local folders. VM users are knowledgeable
enough not to be confused by that. (Emacs is a programmer's editor,
and VM strikes me as a programmer's mail reader. I expect that
everybody who uses either program is technically knowledgeable. The
general public doesn't know that Emacs and VM exist, much less use
them, and never will.)

Yup. I think I agree.

Cheers,
Uday

[Stefan Monnier]

Post by Uday Reddy
The main problem with providing such a function is that it is at odds with
the Emacs philosophy. Long-time Emacs users are used to the idea that they
can make changes to buffers inside Emacs and discard the changes if things
go wrong. In VM, I often end up expunging a folder and then realizing that
I shouldn't have. Then I can reload the folder and return to the version on
the disk or the server. If the changes get saved asynchronously without my
control, I would lose that ability to discard.

I think the way forward is to combine the two: use the DVCS-like model
combined with eager background push&pull.

The DVCS model gives you fast local accesses decoupled from the network
latency, handling concurrent accesses from various machines, and the
ability to recover from mistakes; while the background push&pull saves
you from the need to remember to "save".

The main problem with this model is that DVCS requires the ability to
merge changes, and for such merges to be understandable. This works
great on "text files", but progress has been slow on generalizing it.


Stefan "waiting for a DVCS-based filesystem"