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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers