[2016-09-10 15:22] Philipp
> I want to ask the same questions, what does maildir brings
> us? Support of other tools is not a valid answer. I want
> to hear a feature that improve mmh.
Well actually, I started looking at the nmh mailing list and noticed there is
quite a push for maildir support from some users there, too. Other people on
that mailing list have been explaining the technical benefits better than I
could. Even if there are only a few, there are some benefits. The one most
relevant to me is read/unread support that actually syncs to the IMAP server.
I will contest your assertion that 'speaking the modern day standard' is not an
improvement. You say it is not mmh's fault that MRA do not support MH. I
disagree. It is the responsibility of software to support the current standards-
but it is not required for new software to support older ones, though they may
as a courtesy. How many MRA developers know people still use MH? How many even
know MH ever existed? How many even care? No, reliable MH support is never going
to happen, the change has to come from mmh.
> > I still need further clarification on this point. I'm looking at two of
> > the same plain text email right now: one in mh format, one in maildir
> > format. There are but two differences: filename,
>
> The filename is the reason why we all against Maildir. Maildir has a
> complex way to create this filenames, to avoid locking and to avoid
> expensive filename search algorithms. This design is good for a
> mailserver.
>
> The problem with these filenames is we can't store the order in the
> filenames:
>
> > A unique name can be anything that doesn't contain a colon (or slash)
> > and doesn't start with a dot. Do not try to extract information from
> > unique names.
>
> Quote from the maildir specification[0].
>
> For most MUAs this isn't a problem, because they can store extra
> information (like the order) in memory. Mmh can't do this, because
> the idea is to call a mmh-tool and then get back to the shell.
>
> To get this clear an example[1]:
>
> My current message is
> '1472261450.M199025P71755.bureaucracy.bureaucracy.de,S=7768,W=7986:2,'.
> Now I want to read the next message, can you tell me the filename of
> the next massage? If my current message is 42, the answer is 43 (expect
> for some special cases but they are not that hard to handle).
>
> So we would need extra file to store a mapping between maildir and
> the order the user see. This is a complexity and abstraction we don't
> want.
I see your point. Thank you for elaborating.
> > and a few extra fields
> > in maildir. Maybe there are more differences in terms of attachment
> > storage, but the differences are very slight.
>
> The files should be the same. MH and Maildir store every mail as is and
> one file per mail.
>
> > Using FUSE would be
> > unnecessary; why can you not patch each of mmh's tools to operate on
> > maildir format? I fail to see how a different filename and a few extra
> > lines within the text file create an impossible barrier.
>
> The barrier is not so strong as you mind, most of the mmh have a ``-file''
> switch. With this you can access the mails in a maildir.
Let's get creative. Assuming maildir backend is entirely impossible, but the
mail file contents are identical, rather than using FUSE could we not use
symlinks or hardlinks?
'inc -md' : links are made from maildir to MH.
'refile -md' : numbers are known from links. Move the corresponding maildir
files, destroy and recreate links appropriately
'rmm -md' : remove both link and corresponding maildir file
'sortm -md' : destroy and recreate links according to the sortm parameters
etc
You get the idea. I think this is... sort of inelegant, and yes would add some
complexity as each tool now needs to be aware of links. Maybe you could help me
write a wrapper for each tool to accomplish these tasks in the shell? That might
be the best compromise. What do you think?
> > Yes, Phillip is the one whose friend is working on a 3 way sync, and
> > that seems to be his ideal solution. I find it unacceptable. I'll
> > explain why further below
>
> You are write the current situation of sync sucks, but maildir
> wouldn't change this situation, because syncing of maildir sucks too,
> because the MRAs suck.
>
> I'll give some additional information. Simon don't use mmh, he uses mutt
> and his actually goal is a imap-to-maildir sync, but mh is not that complex
> to implement. He write his client because he thinks all other imap MRAs
> suck.
Why does mbsync/isync suck? What is your friend doing to be better
than other MRAs? Am I mistaken about 3-way sync; will there support for direct
to MH sync in Simon's MRA?
Another issue is, I don't like the idea of relying on a single, specialized
program in my setup. I want to 'future proof' my environment. Let's say your
friend Simon makes an amazing MRA. How long can I expect that to last? What if,
five years from now, a new IMAP auth implementation (or some advancement) is
released? Will Simon still be around to update his MRA? Will he even still be
using it himself? The effectiveness of my setup hinges entirely on one person...
and I fear that we'll be having this exact same conversation several years down
the road: "there are no more MRAs which support MH, why don't we support
maildir?"
Relying on MRAs with MH support is a bandaid, a temporary solution. It will not
last.
> If you want other solutions to this problem you could write was is your
> current setup and what are your requirements. Maybe we find a better
> solution for you.
I enjoy using mmh, but I also own a mobile phone, and I access my mail from a
number of devices where an ssh based interface would be inconvenient. I use many
different devices and many different clients, all of them speak to the central
IMAP server. I just want mmh to be an MUA that works with the MRAs that exist...
> [2]: I have tested it, you can use clawsmail as an MRA for mmh.
Could you please explain how this is accomplished?
Thanks for your patience,
-Link
