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

[Lyndon Nerenberg]

>> Trying to keep everything in sync in the face of errors, without
>> transactions, would require some horribly complicated code.
> 
> You'd work with a temporary directory and atomically rename it to
> mail/inbox/42.

Hmm ... that might be more data copying than I would like, especially over a 
network mount, but yes, I guess it would work.

>> Do you code the MH tools to look for those cases (more complexity), or
>> leave it for the user to notice something is amiss and give them a
>> command to force a rebuild of all sub-files from the master raw file.
> 
> 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 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.  And if you do, you have 
to write the code to ensure that consistency.  Having two different views on 
the same message produce different results is a non-starter.  It simply can NOT 
happen.

> However, there is a precedent in Mat Blaze's Cryptographic File System
>> (CFS)[1].
> 
> 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.

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 I hope it wouldn't slow
> the already slow pick(1) much.

The exploded view would likely speed up pick in many common cases.  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.

BTW, it's that simple metadata cache (on top of the MH-style on disk layout) 
that makes the CMU Cyrus IMAP server so blindingly fast.

--lyndon

signature.asc
Description: Message signed with OpenPGP using GPGMail