[Top][All Lists]

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

Re: [Nmh-workers] indexing

From: Paul Vixie
Subject: Re: [Nmh-workers] indexing
Date: Tue, 08 Feb 2011 02:41:09 +0000

> Date: Mon, 7 Feb 2011 21:17:54 -0500
> From: Jeffrey Honig <address@hidden>
> ...
> Is there any room in an implementation of this that could maintain a
> per-folder as well as a per-store database?

yes, that would be pretty easy.


> From: "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <address@hidden>
> Date: Mon, 7 Feb 2011 17:54:05 -0800
> > .. however, i need to be able to pick, refile -link, rmm, and stuff
> > like that.  ...
> ...
> The Cyrus cache is designed to be blindingly fast.  Ignore it if you
> want, but you'll never cook up anything that approaches it for speed
> and simplicity.  (I have personally dragged away some of the bloody
> carcasses of those who tried ... :-)

if pick, refile -link, rmm, and stuff like that could all work on top of
the cyrus scheme i'd be happy to convert the disk files from MH format
to some other format, or add another format as an overlay (which is what
i'm doing now with sleepycat).  if cyrus has equivilent shell level
commands so i can manage my e-mail from the shell even though it's not
stored in MH format any more i'd consider that too.

what i don't want is to have my lifetime of e-mail only accessible
through imap, because there are not good shell level commands that i can
run from cron or .forward to manage my mail.  if there were such
commands (imagine mutt with a wider CLI, or imagine MH as an imap
client) then the fact that i'd have to have a working and running imap
server before i could access my e-mail would irritate me.  sometimes DNS
or Kerberos or even the LAN is screwed up, and sometimes i need to pick
through my inbox while running in single user mode.

if the cyrus cache layout can be married to MH in the same kind of overlay
fashion that i'm doing right now with sleepycat, then i'll try it out and
let you know.  one of the drains i am circling but refusing to go down is
where we end up creating a mail access API with C bindings and then teaching
MH and other unix mail tools to use it.  that'd be lipstick on the pig.

MH has been the road not taken for some right and wrong reasons.  IMAP has
ended up filling a vacuum while still sucking some.  my preferred approach
has been marginalized by approaches that make sense to the next generation,
who don't mind giving their n-tuples to cloud operators, and who seem to
get a lot less e-mail than i do and save almost none of it.  overall: OUCH.

reply via email to

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