Re: [Nmh-workers] Locking. Horrible, horrible, locking ...

[Ken Hornstein]

>> Given those things I felt the best solution was to make the locking
>> run-time selectable.
>
>So how and when do you change this at run time?  I.e., what software
>is nmh not getting along with that requires it to change its locking
>behaviour.  And how, practically, do you change it on the fly? This
>seems to require wrapper scripts that set alternative MH profiles with
>different locking settings.  Does anyone actually do this?  A concrete
>example would help everyone understand the problem.

I never envisioned that people would be changing it regularly; it was
always in my mind that you'd set it once, and that would be enough.
The mechanics of changing are simple: just edit your .mh_profile or
mts.conf.  It just sucked that previously you had to recompile it.
But I'll give you a concrete example: the filesystem that I use for
$HOME only works right if you use lockf(), but that's a lousy choice in
general.

>And just as we must comply with the locking scheme the system mail spool
>uses, anything that pokes around in ~/Mail/ needs to comply with our
>choice of locking.

Well, that's a nice theory ... the actual fact of the matter is for
all practical purposes, non-MH programs that poke around in ~/Mail
don't do any locking at all (look at the Claws Mail archives to see
the "screw you, hippie" answer Steve Rader got when he complained about
that).

>This whole runtime adaption business seems like an invented problem.
>And again, I make the case that no other MUA I've come across needs this
>to function properly.  If there is a counter-example that proves the
>need, I'm all ears and eyes.  But in the absence of one, I don't see the
>need.

Are you complaining about the "spool locking" runtime setting, or the "lock
everything else" runtime setting, or both?  If the the concern is about
the "lock everything else" runtime setting, the answer to that is simple:
if you have a monolithic MUA, you don't need to do any data locking, so
nmh really is unique here.  For spool locking ... well, maybe you could
make a case that is an issue.  But I'm really trying to understand why
runtime configuration of _anything_ is bad; having to recompile a program
to change a setting just seems lousy to me.

--Ken