Hi,
Do you run nmh on an OS and architecture that isn't in this list?
If so, what version of MH/nmh, OS, and architecture?
androidarm
darwin 386 amd64 arm arm64
dragonfly amd64
freebsd386 amd64 arm
linux 386 amd64 arm arm64 ppc64{,le
i do all new work in Go.
i just don't know whether MH can attract new users through a rewrite.
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hi Paul,
> i just don't know whether MH can attract new users through a rewrite.
That wouldn't be the aim. The aim would be for the existing users to
have a code base that allowed more rapid, stable development of new
features, deprecating old warts, and improving consistency.
For example, whil
>I ideally ask because of an off-list comment received of being tempted
>to re-write nmh in Go. That would be my first choice in starting today
>too. I've been programming C on Unix since the 80s, and it's seen off
>inferior allcomers like Java and C++, but Go is the one to replace it
>for many p
>For example, whilst I like the Unix idiom of one command to do one thing
>well, I do find myself doing a series of picks, marks, and scans to
>whittle down emails whereas having a consistent, planned, notation that
>can be used wherever a message number can be given would lessen the
>iterations a
Ken Hornstein wrote:
...
But ... one nasty problem raises it's head. That is the lack of _time_.
We have plenty of great ideas, but those of us who want to implement
them all suffer from a lack of time to work on them. Rewriting nmh in
Go seems like it would take a long time. Slowly switchi
Hi Paul,
> if we wanted a better code base for the same graying user population,
> wouldn't we do a gradual rewrite in some well-disciplined subset of
> C++ instead?
No, everyone has a difference subset so we won't agree. There's nothing
to enforce it automatically. No subset of C++ is nice. A
Ralph Corderoy wrote:
Hi Paul,
if we wanted a better code base for the same graying user population,
wouldn't we do a gradual rewrite in some well-disciplined subset of
C++ instead?
No, everyone has a difference subset so we won't agree. There's nothing
to enforce it automatically. No sub
Hi Paul,
> that's a knee-jerk reaction.
Very true. A regurgitation of a long-held view.
> bert hubert at powerdns found a subset he can live with, and ways to
> enforce it. basically there are no operators overloaded and no
> subclassing.
I've struggled to find something on this, e.g. a guide
Ralph Corderoy wrote:
Hi Paul,
that's a knee-jerk reaction.
Very true. A regurgitation of a long-held view.
bert hubert at powerdns found a subset he can live with, and ways to
enforce it. basically there are no operators overloaded and no
subclassing.
I've struggled to find something
On Mon, 12 Feb 2018 13:15:08 -0800 Paul Vixie wrote:
>
> Ralph Corderoy wrote:
> >
> >> he wanted new(), and methods, and garbage collection.
> >
> > GC as in https://en.wikipedia.org/wiki/Smart_pointer#Features ?
> > So analyse and switch from C pointers to the various C++ kinds?
>
> i didn't e
>As I showed, the perf loss via
>using GC with nmh is tolerable and this is without doing any
>cleanup or code improvement based on profiling.
Errr ... were there some other messages where this assertion was made?
Because my takeway was that with garbage collection it was MUCH MUCH
worse. Like, "
On Mon, 12 Feb 2018 17:35:13 -0500 Ken Hornstein wrote:
Ken Hornstein writes:
> >As I showed, the perf loss via
> >using GC with nmh is tolerable and this is without doing any
> >cleanup or code improvement based on profiling.
>
> Errr ... were there some other messages where this assertion was m
On Mon, 12 Feb 2018 09:27:04 + Ralph Corderoy wrote:
Ralph Corderoy writes:
> Hi Paul,
>
> > i just don't know whether MH can attract new users through a rewrite.
>
> That wouldn't be the aim. The aim would be for the existing users to
> have a code base that allowed more rapid, stable deve
>There was a fair bit of variability but it was no worse than
>twice as slow and often close to par.
Um ... are we looking at the same results? Because I would classify
the results as "on average, more than twice as worse", and I could NOT
in any universe say "often close to par" (I am going by t
Ken Hornstein wrote:
...
you said:
And the programs I tried worked fine. Running best scan time
for 200K messages, scan+gc takes 13.5 seconds while the
regular scan 7.4 seconds.
To me a performance penalty of 50% is not worth it, but I'd be willing
to hear from others.
the various design
>note: because valgrind finds hundreds of thousands of runtime anomalies
>in even a trivial libcurl application, and because the suppression file
>syntax for valgrind doesn't permit me to say "if it comes from libcurl
>just ignore it", i'm currently at wit's end in verifying my heap memory
>man
Ken Hornstein wrote:
Some smart-ass on this list recently gave me a flippant response when
I made a similar lament regarding valgrind on MacOS X. Who was that
again? :-)
i normally hate people like that, but did he say, here kid, here's a
nickel, get yourself a better C library for accessin
Paul V wrote:
> note: because valgrind finds hundreds of thousands of runtime anomalies
> in even a trivial libcurl application, and because the suppression file
> syntax for valgrind doesn't permit me to say "if it comes from libcurl
> just ignore it",
Doesn't something like this?
{
if uninit
Ralph wrote:
> The aim would be for the existing users to
> have a code base that allowed more rapid, stable development of new
> features, deprecating old warts, and improving consistency.
+1
I'd rather see more of all the above, even if it means giving up some
current capabilities. I don't th
On Mon, 12 Feb 2018 15:26:18 -0800 Paul Vixie wrote:
>
> Ken Hornstein wrote:
> ...
> > you said:
> >
> >> And the programs I tried worked fine. Running best scan time
> >> for 200K messages, scan+gc takes 13.5 seconds while the
> >> regular scan 7.4 seconds.
> >
> > To me a performance penalty o
On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie wrote:
>
> if we wanted the effort of an actual rewrite, we would need to justify
> the time expenditure with a potentially larger user population, which
> means reconsideration of features that younger people actually depend
> on, like imap and mi
David Levine wrote:
Ralph wrote:
The aim would be for the existing users to
have a code base that allowed more rapid, stable development of new
features, deprecating old warts, and improving consistency.
+1
I'd rather see more of all the above, even if it means giving up some
current capab
Bakul Shah wrote:
On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie wrote:
if we wanted the effort of an actual rewrite, we would need to justify
the time expenditure with a potentially larger user population, which
means reconsideration of features that younger people actually depend
on, like im
I think this would be a great idea. How much (volunteer!) time
is being wasted chasing down memory leaks? If we have the
resources to do so, of course
(Of course, it's easy for me to say, "Go for it!" I still
haven't found time to contribute even a regression test. B-)
>i'd like to provide the MH view via FUSE rather than files-on-disk.
>rather than using command line utilities to extract a mime part, i want
>to access it by ~/Mail/inbox/135/part1.exe or whatever.
I've already given my thoughts on this, but ... really, if someone wants
to do this, have at it!
Paul Vixie wrote:
>> On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie wrote:
>>> if we wanted the effort of an actual rewrite, we would need to
>>> justify the time expenditure with a potentially larger user
>>> population, which means reconsideration of features that younger
>>>
>We've talked a lot about the subtle change to move MH to Maildir, and we
>never quite work out all the wrinkles, and I'd sure like to that.
I hear people say this, and I have to wonder ... what's the goal here?
If the goal is to share your mailbox with another client (or maybe
IMAP server) that
Hi David,
> > The aim would be for the existing users to have a code base that
> > allowed more rapid, stable development of new features, deprecating
> > old warts, and improving consistency.
>
> +1
>
> I'd rather see more of all the above, even if it means giving up some
> current capabilities.
Michael Richardson wrote:
...
So what you mean is that you want an MH-like file arrangement consistently
provided over many transports via FUSE. I'm with you on this.
On top of that, I'd like a personal IMAP server, *solely* so that my local copy
of Thunderbird (or maybe my smartphone IMAP cl
Ken Hornstein wrote:
We've talked a lot about the subtle change to move MH to Maildir, and we
never quite work out all the wrinkles, and I'd sure like to that.
I hear people say this, and I have to wonder ... what's the goal here?
If the goal is to share your mailbox with another client (or
Ken Hornstein wrote:
in that world, inc would speak Maildir format
Done! inc has been able to grok Maildir format for ... over 6 years now.
i underspoke. i mean inc could only write into Maildir format folders,
and all MH folders would become read-only, available translucently, or
conver
Ken Hornstein wrote:
>> We've talked a lot about the subtle change to move MH to Maildir, and we
>> never quite work out all the wrinkles, and I'd sure like to that.
> I hear people say this, and I have to wonder ... what's the goal here?
> If the goal is to share your mailbox w
Paul Vixie wrote:
> Michael Richardson wrote:
>> ...
>> So what you mean is that you want an MH-like file arrangement
consistently
>> provided over many transports via FUSE. I'm with you on this.
>>
>> On top of that, I'd like a personal IMAP server, *solely* so that my
Michael Richardson wrote:
... I tried to build the other one (uw-imap?) that had MH support, but
it was too much effort because the "libmh" library was pretty much impossible
to build/configure.
sorry about that. (i was the maintainer in the years up until mark's
death.) the ruinously bad pr
paul wrote:
>
>
> Michael Richardson wrote:
> > ... I tried to build the other one (uw-imap?) that had MH support, but
> > it was too much effort because the "libmh" library was pretty much
> > impossible
> > to build/configure.
>
> sorry about that. (i was the maintainer in the years
Hi Michael,
> I don't know if rewriting MH in go or rust would be better. I am
> half-way through each book (one in each bathroom...).
No, not Rust. Eric has summed up its problems quite a few times and
mentioned it in those three `Go's replacing C' posts I gave. It lacks
Go's pedigree, self-r
>sorry about that. (i was the maintainer in the years up until mark's
>death.) the ruinously bad property of uw-imap's MH implementation, which
>i could not fix due to an impedance mismatch between the protocol and
>the MH message number definition, is that whenever you refile a message,
>both
Ken Hornstein wrote:
> On that same IMAP-managed directory ... well, what exactly HAPPENS there
> is a bit unclear to me. Specifically, the IMAP servers I've looked at
> (Cyrus-IMAP and Dovecot are the ones talked about here) all maintain
> their own index into the Maildir directo
>> On that same IMAP-managed directory ... well, what exactly HAPPENS there
>> is a bit unclear to me. Specifically, the IMAP servers I've looked at
>> (Cyrus-IMAP and Dovecot are the ones talked about here) all maintain
>> their own index into the Maildir directory. If we put a n
Ken Hornstein wrote:
... Well, good question! I believe the answer to that is "no".
You can read the base specification here:
https://cr.yp.to/proto/maildir.html
The idea is when you are delivering a new message into a Maildir, you
first write it to the "tmp" directory, then rename
>> Now if we refile a message, do we put those messages in "new"? Maybe?
>> But then they won't be visible to other programs until the true "manager"
>> of that mailbox notices it. If we scan a Maildir folder, should we be
>> in charge of moving stuff from new into cur? Maybe? Maybe not? You
>
Ken Hornstein wrote:
You know, it might be interesting to see the output from inotifywait
when you do a drag and drop across folders. I am presuming that
Thunderbird doesn't know about the Cyrus-IMAPd index and Cyrus IMAPd just
figures it out. If that's the case then that is fine.
the imap
>the imap service's relationship to its backing store is none of my
>business as an imap client. as long as invariants are preserved, the
>precise form of magic, or even what upstream rules might be getting
>broken, are "all fine by me".
Well, I didn't care that much about what Cyrus IMAPd was
Thus said Ken Hornstein on Tue, 13 Feb 2018 11:30:38 -0500:
> >We've talked a lot about the subtle change to move MH to Maildir, and
> >we never quite work out all the wrinkles, and I'd sure like to that.
>
> I hear people say this, and I have to wonder ... what's the goal here?
Again, as one of
Thus said Ken Hornstein on Tue, 13 Feb 2018 10:09:07 -0500:
> But Bernstein ignored MH because he was not trying to invent a MAILBOX
> format, he was trying to invent a mailDROP ... really, I went back and
> looked. Yes, I know people now use Maildir as a mailbox, and I think
> that's weird, but
Thus said Ken Hornstein on Wed, 14 Feb 2018 14:22:56 -0500:
> If we scan a Maildir folder, should we be in charge of moving stuff
> from new into cur? Maybe? Maybe not? You tell me!
Let's look at what qmail-pop3d does when a client ``scans'' the list of
messages:
$ find new -type f| wc -l
Andy Bradford wrote:
Thus said Ken Hornstein on Tue, 13 Feb 2018 11:30:38 -0500:
We've talked a lot about the subtle change to move MH to Maildir, and
we never quite work out all the wrinkles, and I'd sure like to that.
I hear people say this, and I have to wonder ... what's the goal here?
Ken Hornstein wrote:
the imap service's relationship to its backing store is none of my
business as an imap client. as long as invariants are preserved, the
precise form of magic, or even what upstream rules might be getting
broken, are "all fine by me".
Well, I didn't care that much about wh
>As a longtime (and current) qmail user, I'm interested in understanding
>this argument more in detail; e.g. where did you go back and look to
>support the claim that he was trying to invent a maildrop?
>
>>From http://cr.yp.to/qmail.html:
Well, this web page for one.
But I guess on fur
Ken Hornstein wrote:
... In my mind a mail DROP is where an MTA drops off email
for some later program to pick up, not necessarily where mail is stored
for manipulation by a MUA, and a lot of the Maildir documentation is
talking about how there's a special delivery directory ("new"). But
since
>Again, as one of the few remaining qmail users, I've never really seen
>the need for MH to move to Maildir. What exactly would I gain by that?
Well, you can read the many messages on this topic from someone who will
remain nameless, but who's name rhymes with "Maul Pixie".
But ... let me see i
>However, as soon as I send QUIT to my qmail-pop3d daemon, it moves that
>message from Maildir/new to Maildir/cur:
>
>$ find cur -type f| wc -l
> 2
>$ find new -type f| wc -l
> 0
>
>Does that mean that MH scan should do the same?
Hrm. I am undecided. Maybe?
--Ken
--
Nmh-workers
h
Ken Hornstein wrote:
... So it would be helpful if we supported Maildir as a mailbox
format, because then we could use nmh directly on the backend store
without going through IMAP (to me that suggests that really you want
IMAP support in nmh, but, whatever). ...
if MH could speak IMAP and if
>if MH could speak IMAP and if pick(1) could use Sieve, life would be great!
I understand the first part of that sentence (like I've said previously,
I see no fundamental problems with that, just a matter of engineering).
But how do you envision the second part working? My limited
understanding o
ken wrote:
> ... I was also wondering if
> we do a "refile +/path/to/dovecot/folder 42", should we put the message
> in "new" or "cur"? Since it seems (in the singular instance of Dovecot)
> that "new" is for messages that are flagged as \Recent, and I don't think
> refiled messages should c
>wouldn't that break the Maildir "protocol" for creating unique filenames?
>do other programs create files in "cur" directly?
My reading of the specification is "no".
AFAICT, the way it's supposed to work is:
- You create a unique filename in the "tmp" directory, and write it out.
- You then ren
ken wrote:
> >wouldn't that break the Maildir "protocol" for creating unique filenames?
> >do other programs create files in "cur" directly?
>
> My reading of the specification is "no".
>
> AFAICT, the way it's supposed to work is:
>
> - You create a unique filename in the "tmp" director
Thus said Ken Hornstein on Thu, 15 Feb 2018 22:35:04 -0500:
> Well, you can read the many messages on this topic from someone who
> will remain nameless, but who's name rhymes with "Maul Pixie".
In the scenario that he who shall remain nameless presented, I can
definitely see the need fo
Thus said Ken Hornstein on Fri, 16 Feb 2018 10:44:06 -0500:
> Right, I was wondering if Dovecot was cool with other Maildir clients
> modifying its store; the answer is "yes". I was also wondering if we
> do a "refile +/path/to/dovecot/folder 42", should we put the message
> in "new" or "cu
>Is there a documented pros/cons discussion of MH mailstore vs Maildir.
>They do have similar structures in that a Maildir stores individual
>messages in individual files. I've often wondered what I might gain from
>switching to Maildir (it's benefits are clear with respect to locking
>an
>I suppose that depends on the meaning of the word ``deliver'' and also
>whether or not the refile command is moving message 42 from the same
>filesystem, or crossing filesystem boundaries. In the former case, it's
>an atomic operation, but in the latter case, to retain the ``crash
>pr
Hi Paul,
> > What specific mime related features do you have in mind?
>
> i'd like to provide the MH view via FUSE rather than files-on-disk.
> rather than using command line utilities to extract a mime part, i
> want to access it by ~/Mail/inbox/135/part1.exe or whatever.
Right, like http://man.
Hi,
Paul V. wrote:
> i get it. however, in cyrus imap, all my folders are in Maildir
> format, and the performance and agility benefits of having so much
> metadata stored in the file name, are unavoidably wonderful.
Can someone with Cyrus IMAP give examples of the file-name metadata.
--
Cheers
Ralph Corderoy wrote:
...
Right, like http://man.cat-v.org/plan_9/4/upasfs
...
Would it be presenting a read-only view of the master storage, and that
storage can still be diddled with by any Unix command?
read-only would be a successful MVP, but eventually, read-write is nec'y.
--
P Vixi
Ralph Corderoy wrote:
...
Can someone with Cyrus IMAP give examples of the file-name metadata.
it was dovecot not cyrus-- my apologies again to all for that confusion.
https://wiki2.dovecot.org/MailboxFormat/Maildir
--
P Vixie
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-
>> hold onto your hats because i'd also like to do this even for imap
>> mailboxes which are not present in my file system at all, and Maildir
>> mailboxes which are present but not in the format MH thinks they are.
>
>OK. I think past mentions of
>https://en.wikipedia.org/wiki/Filesystem_in_Users
>Can someone with Cyrus IMAP give examples of the file-name metadata.
I know Paul already replied to you, but SINCE I had just looked at that
code for Cyrus-IMAPd I figure it might be useful information.
Mailboxes (or folders if you prefer) consist of individual messages stored
in files in the fo
Hi,
Paul V. wrote:
> it was dovecot not cyrus-- my apologies again to all for that confusion.
> https://wiki2.dovecot.org/MailboxFormat/Maildir
Some interesting bits from there.
`Note that messages must not be modified once they've been delivered.
IMAP (and Dovecot) requires that messages are im
Hi Ken,
> The web page that Paul posted in his reply to you has a very good
> description of how Dovecot uses Maildir; some metadata stored in the
> filename are the file's size (to avoid a stat() call)
It was probably Pike that said a cache is bugs waiting to happen. :-)
Maildir seems ill-suit
>It was probably Pike that said a cache is bugs waiting to happen. :-)
I'm not disagreeing, but ...
>Maildir seems ill-suited to MH's needs as an `emails are files, use
>Unix' store. But then that wasn't its aim. Does the rest of the world
>just need IMAP access to the emails, e.g. for webmail
On Sat, 17 Feb 2018 19:53:05 -0500 Ken Hornstein wrote:
Ken Hornstein writes:
>
> Paul has been nibbling around the edges of saying this, but I would
> summarize his OVERALL point is that MH/nmh is used by a tiny, TINY
> fraction of email users, the way people use email has been changing,
> we're
Ken Hornstein wrote:
Here is my $0.02 on that topic.
...
strong +1 to ken's analysis here, and below where he questioned the
utility of developing our own IMAP server. in more detail, this topic:
Now I am not suggesting that we replace the MH mailstore with Maildir;
that doesn't seem suc
>from there, implementing Maildir might be easier than from here. even
>IMAP isn't impossible, if we're willing to return a socket descriptor
>instead of a file descriptor, or maybe a pipe from a fork, or (gag me) a
>temporary file.
Wlll ... I think, sadly, that to really make things like I
Ken Hornstein wrote:
from there, implementing Maildir might be easier than from here. even
IMAP isn't impossible, if we're willing to return a socket descriptor
instead of a file descriptor, or maybe a pipe from a fork, or (gag me) a
temporary file.
Wlll ... I think, sadly, that to really
>> Wlll ... I think, sadly, that to really make things like IMAP a win
>> we need to abstract out things a bit more.
>
>that sounds right. however, i'm not sure if you're saying that
>abstracting out the POSIX stuff so that it can also handle Maildir is
>not a good first correctness-preservin
76 matches
Mail list logo
