[2016-09-09 09:35] Link Satonaka <link.saton...@outlook.com> > > [meillo] > > > [Link] > > > What does the MH format do for us?
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. > > This is like asking: What does the hierarchical inode-based > > filesystem do for Unix? -- The answer is: It it the basis and core > > of everything. > > > > You're not the first one to suggest using maildir as the mmh > > storage. The main reason why we don't do it is that it is not > > possible to simply exchange the storage backend and still have the > > same mmh. Similar: If you would replace the hierarchical > > filesystem with something else, then it would not remain being Unix, > > but something else. Well, it is not necessarily bad if it becomes > > something else, but if you try to invent emailing anew, then it > > would be much better to start completely from scratch. There are a > > bunch of projects that go this way. Steering mmh on the same track > > would not be successful. This is the reason why we don't > > ``simply'' exchange the storage backend. > > > > What would be possible is making the MH storage virtual in sense > > of FUSE and translating into maildir or IMAP. I think this approach > > has some potential, but FUSE (AFAIK) has bad reliability and bad > > portability. > > > > > [Dmitry] > > > MH format is beautiful by virtue of simplicity and friendliness to > > > command line processing. > > > > Well said! :-) > > 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. > 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. > I'm not > suggesting it's a small task, but I do not see how changing the backend > will cause it to suddenly "not be mmh anymore". If I switch from ext4 to > xfs, my OS doesn't suddenly stop being Linux. Unless there is some > reason having MH is critically fundamental to the functionality of each > tool... You can't compare this two think. The MH-Data-structure was designed for MH (mail handler) and MH was designed for the MH-Data-structure. All tools and the hole library is based on this data-structure. > > [meillo] > > > [Dmitry] > > > Keep in mind, not everyone shares your assumption, that > > > synchronization with mailserver (aka IMAP) is good and > > > modern. > > > > Indeed. In my case, for instance, mail exists in the MH format > > only! Incoming mail is passed from the MTA to the MDA, which > > delivers it directly to the MH storage. I use mmh on the > > mailserver directly, to where I ssh. > > I was afraid I'd bump into this. Let me assure you that my "assumption" > IS how email works now. I understand your privacy concerns, but you > cannot, *cannot* deny that synchronization with a mailserver is > imperative. Of course, I don't expect mmh to be anything other than a > MUA, but I *do* expect it to store email in an MRA compatible format. My > request does not hurt your workflow in any way, it just makes mmh more > flexible and modern. MH is MRA compatible, but sadly there are only a few MRA with support MH. In other words: We can't do anything about MRAs don't support MH. MH is simpler to implement then maildir, but most MRA don't implement it. > > [meillo] > > > [Link] > > > As it stands, the only way to > > > actually sync mmh with a mailserver is to convert maildir or mbox to > > > MH. Every single time you sync. With the help of this mailing list, > > > I’ve written a script (which I’ve aptly named ‘inc’) to pull new > > > content from my mailserver to a maildir, then move that into mmh > > > using rcvstore. > > > > This is not the only way to do it. Philipp has a fairly usable > > setup (AFAIK) that does not use rcvstore(1) or such stuff. His MH > > storage is automatically synced with the IMAP server both ways > > (AFAIK). It's semiautomatic, I have to trigger the sync. > 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 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. > > [meillo] > > Learn about the Unix philosophy, and you'll have good chances to > > understand it. > > It's the consequence of the probably most important lesson of > > Unix: Do one thing and do it well! > > It is the basis of the Unix Philosophy on which I request maildir > format. There is a part of the philosophy you conveniently omitted: > > "Expect the output of every program to become the input to another, as > yet unknown, program. Don't clutter output with extraneous information. > Avoid stringently columnar or binary input formats. Don't insist on > interactive input." > > Maildir is the format other relevant programs can read > and expect to find. MH is a dead end and does not fit neatly into the > Unix philosophy. Sure, we can string together a script of a half dozen > other tools to achieve this functionality, (at the expense of > efficiency), but... I don't understand why this speaks again mh? The output of most of the tools is good to handle, we are scriptable and the input are either mails or numbers. In MH aren't any extraneous information, the order is one of the most impotent information we store. Again we don't make it hard for other tools to interact, but we can't force them to use our interface. > There is another philosophy I subscribe to: suckless. In fact, this is > why I love mmh: you have created the most suckless mail client I know > of, and I applaud you for that. > http://suckless.org/philosophy > > But there is one misstep, one old bit of the original MH still hanging around > and getting in the way. Writing scripts to move mail around, converting > between > formats- an unsightly, inefficient glue between two programs. This is not > suckless. This is not good. What other option is there? A 3-way sync MRA? The > complexity of that setup is mind numbing, no matter how you approach it. There > is one graceful solution: an mmh which speaks maildir. 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. There are other solutions like fetchmail, sshfs, clawsmail[2] or even Dropbox. Depending on the requirements one or another solution is recommendable. 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. [Link] in another mail [2016-09-09 18:52] > As I have explained twice now, I am not telling you to change your workflow. > My > request does not require that you change your workflow. At this point, you are > merely telling me that I, and the vast majority of email users, are not > welcome > to use mmh. No, we are telling you that mmh don't support maildir and has no plans to change this. If you want features from other programs you have some options: 1) patch the program to support mh (they might say no) 2) ask if mmh implement this feature (we might say no) 3) search for another tool with this feature and mmh support 4) write a program with mh support and that feature Philipp [0]: https://cr.yp.to/proto/maildir.html [1]: The filename is created by dovecot for a mail in my inbox. [2]: I have tested it, you can use clawsmail as an MRA for mmh. If someone wants more information, just ask.
pgpPQh6jcLY8J.pgp
Description: PGP signature
