Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

[Ralph Corderoy]

Hi Lyndon,

> > You have an fsck-like that can report inconsistencies, this is
> > simply the unpack followed by a diff, and would likely be the same
> > command that refreshes.  Just as now, if the user edits
> > mail/inbox/42 then he's expected to know how to miss shooting his
> > foot.  This is Unix.
> 
> No, it's not that simple.  If you edit the message file in the current
> store, by definition the change is in sync with itself – there's
> nothing to get out of sync with.

But you can break the email such that nmh dislikes it.  Just as corrupt
emails arrive from Wordpress that it also dislikes.

> But in the exploded directory view, there is.  And you can define all
> you want, but at the end of the day you have to state if you guarantee
> a consistent internal view across all the files, or not.

Clearly, if there's two files with overlapping representations of the
same data then nmh is not guaranteeing for evermore that just one of
those can't be edited without using nmh.  Nor should it.  To check all
parts are consistent on every access would be silly.  I can `mhstore 42'
now to create 42.html alongside the original;  nmh does nothing to spot
that I then run a HTML formatter on it.  nmh continues to use the
master;  42.

> Having two different views on the same message produce different
> results is a non-starter.  It simply can NOT happen.

nmh's results would always be based on it reading the stated master
data;  it would be consistent.

> > It's an idea, though every user would need a mount to match their
> > ~/mail.  And then I have other folders outside of there referenced
> > with +/some/path that would need more mounts.
> 
> Just as with native Plan9 upasfs, you would have to run multiple
> instances.  That's not a problem in practice.  On my Plan9 machines I
> regularly have a half dozen upasfs instances in play.

But then it's fundamental to Plan 9 to expect many mounts by the user.

> In the UNIX case it would be even simpler, since a single 'nmhfs'
> instance would serve the entire folder tree.  On Plan9 I have to start
> a separate upasfs instance for each 'folder'.

And on Unix, directories outside of ~/mail would also be a mount each.
I often use a temporary directory as a discardable workplace for emails,
switching to it with `+.'.  That would now require a mount each time.

> > And I hope it wouldn't slow the already slow pick(1) much.
> 
> The exploded view would likely speed up pick in many common cases.

Agreed, if the master versions of the needed data were the decoded, one
header per line, etc., versions.

> One of the things the fileserver does is create a dynamic cache of the
> metadata for messages in the folder.  By caching commonly-used header
> content (From, To, CC, Subject, Date), many common pick operations
> wouldn't need to directly touch any of the message files.

pick currently reads only a block or two of an email, stopping at the
/^$/, if it only needs the headers.  It could switch to the `decoded
headers' file instead.  Not as fast as an indexed cache, but still an
improvement and without yet another representation of the data around.
Is the headers file the master, or the cache?

A directory tree representation would also make `find all messages with
large PNGs somewhere amongst their MIME hierarchy' trivial.

Cheers, Ralph.