[Top][All Lists]

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

Re: [Nmh-workers] Future directions for nmh

From: Conrad Hughes
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Thu, 17 Mar 2016 10:26:32 +0000

Ken> You run command (a) which changes the context.  How is command (b)
Ken> supposed to know that the context has been changed?

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.

There's a problem there though, in that context only records your
current folder, with sequences being folder-local — 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 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.


reply via email to

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