nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Future directions for nmh


From: Ken Hornstein
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Thu, 17 Mar 2016 23:49:56 -0400

>Given your mentioning of MHCONTEXT, I could envisage a wrapper for MH
>commands much like Paul Fox's example — perhaps a context directory
>containing per-shell-PID context files, and the crucial test would be
>whether another context file was more recent than and different to this
>shell's one when you take an action.

... that seems like a complicated mess prone to race conditions if you
don't do some locking.

>There's a problem there though, in that context only records your
>current folder, with sequences being folder-local

That is not true; you can have 'private' sequences which are stored in
the context, so in theory you could have different sequences for each
shell.  That might not be so great for things like the unseen sequence,
though (but you can have some sequences public and others private).

>— so a sortm in one
>shell could render a previous scan in another shell obsolete.  Trying to
>solve that by merging all sequences up into context would introduce
>other difficulties: for example sortm would have to rewrite *all*
>context+sequence records containing sequences affected by the sort.  The
>difficulty of tracking that probably renders Paul's approach ("Something
>happened somewhere else — you're about to affect message(s) X — are you
>sure?") safer.

I'm fine with Paul's approach, but I think it should remain as an add-on;
I don't think it makes sense to integrate it into nmh.

>I don't use other message stores, but it seems to me that maintaining a
>map of MH unique IDs to another store could be quite closely related,
>and perhaps Paul's approach would still apply: it's simple and safe,
>although it could be inconvenient if "third party" changes couldn't be
>tracked at a sufficiently fine granularity.

I am not sure it's appropriate.  If you look at the email I posted about
how I envision nmh would work with IMAP, it should be obvious from it
that the scheme I proposed would (hopefully) be relatively resistant to
problems if the backend store was changed.  Replace "UID" with "filename"
in that message, and you could probably use the same scheme with Maildir.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]