> Date: Mon, 7 Feb 2011 21:17:54 -0500
> From: Jeffrey Honig
> ...
> 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)"
> Date: Mon, 7 Feb 2011 17:54:
>
>
> noting that slocal already links to either db, ndbm, or gdbm (according to
> portability logic in the Makefile) i've thought of adding a per-folder
> index
> (so, ~/Mail/inbox/.mh.db or similar) that maps these number sequences to
> each other.
>
I've had some ideas around this in the past f
> yes, i saw that. dovecot has something similar. however, i need to be
> able to pick, refile -link, rmm, and stuff like that. and, i'm
> fundamentally itchy about using an imap server's internal representation
> since i like to imagine imap as an access method rather than as a closed
> ecosyst
Hi belg4mit,
> > (As an aside, I really dislike grep and friends no longer coping
> > well under ~/mail because of base 64 encoding, etc.)
>
> I usually use scan `pick -search` for that sort of functionality, but
> if that's not to your liking you might look at hacking on transparent
> base64 dec
> Date: Sat, 5 Feb 2011 12:23:51 -0800 (PST)
> From: Lyndon Nerenberg
>
> Paul, you should take a look at how the CMU Cyrus IMAP server organizes
> it's on-disk message store. It's pretty much an MH folder tree with a
> per-folder index and cache of useful headers.
yes, i saw that. dovecot has
>(As an aside, I really dislike grep and friends no longer coping well
>under ~/mail because of base 64 encoding, etc.)
I usually use scan `pick -search` for that sort of functionality,
but if that's not to your liking you might look at hacking
on transparent base64 decoding to http://search.cpan
Lyndon Nerenberg wrote:
> And as with the existing sequences imlementation, the only way you get
> 100% consistency is by making the message store a black box, at which
> point it's no longer MH.
Very non-MH in implementation, but perhaps similar in ethos is to have a
file server that presents th
The pithy ruminations from Paul Vixie on Re: [Nmh-workers]
indexing were:
[SNIP!]
=>more important is performance. i'd like to be able to know thousands of UIDs
=>in a folder without opening thousands of files to get them. and, basically,
=>i want MH itself to go
2. Can IMAP unique IDs and such be stored as X-Header stuff?
Not reliably. The UID of a message is only meaningful within the context
of a folders UIDVALIDITY, and that can change behind MH's back. And
really, these are message store properties, not attributes of the messages
themselves. T
> Date: Sat, 05 Feb 2011 19:37:53 -0800
> From: Jon Steinhart
>
> I'm not an expert on IMAP. I don't use it and know very little about it.
at this point i don't think anybody does, not even mrc -- it's gone organic.
> But not being completely afraid to make a fool out of myself I have
> two th
I'm not an expert on IMAP. I don't use it and know very little about it. But
not being completely afraid to make a fool out of myself I have two thoughts:
1. I added code to nmh years ago that calls external hook programs when
messages are inc'd, rmm'd, and refiled. It does the right thi
> From: valdis.kletni...@vt.edu
> Date: Sat, 05 Feb 2011 20:22:35 -0500
>
> I've seen this idea several times, and I always have the same question
> - how would we deal with index/cache synchronization? One of the
> reasons I'm still using MH/exmh is because the one message per file
> paradigm me
I've seen this idea several times, and I always have the same question - how
would we deal with index/cache synchronization? One of the reasons I'm still
using MH/exmh is because the one message per file paradigm means that you can
do interesting things with regular Unix commands - except if you
On Sat, 05 Feb 2011 12:23:51 PST, Lyndon Nerenberg said:
> Adding the index/cache files to the native MH file store would make most
> MH commands blazingly fast, the obvious benefits being to scan and pick.
I've seen this idea several times, and I always have the same question - how
would we dea
i can also imagine storing the full rfc822 header object in this index so
that "scan" and many forms of "pick" can operate at the speed of modern
hardware. (stat()'ing ten thousand files in a directory has not gotten
faster over the years, whereas dbm_read()'ing 1 elements has gotten
really q
> From: Ken Hornstein
> Date: Fri, 04 Feb 2011 22:04:07 -0500
>
> Glad to see you're still using nmh, Paul!
i'm on the fence at the moment, but giving it my best shot.
> So, when people talk about integrating nmh and IMAP, there are two distinct
> problems that people want to attack (AFAICT):
>
On February 4, 2011, Ken Hornstein wrote:
> Paul Vixie wrote:
> >
> > hi all. i havn't worked on mh in quite a while. i sent kenh some patches
> > to use locking on the 'context' files back in 2003 and i see that those made
> > it in. previously i guess it had been a REALLY long time since i
>hi all. i havn't worked on mh in quite a while. i sent kenh some patches
>to use locking on the 'context' files back in 2003 and i see that those made
>it in. previously i guess it had been a REALLY long time since i hacked mh:
Glad to see you're still using nmh, Paul!
>noting that slocal alr
hi all. i havn't worked on mh in quite a while. i sent kenh some patches
to use locking on the 'context' files back in 2003 and i see that those made
it in. previously i guess it had been a REALLY long time since i hacked mh:
To: mh-work...@ics.uci.edu
Subject: Getting MH 6.8.3
19 matches
Mail list logo
