5 ms·

I will not beat a dead horse with my "mutt is superior because they know the best they cannot do is suck without confessing it" trope, but almost all email clie

by 616c 10y ago

I will not beat a dead horse with my "mutt is superior because they know the best they cannot do is suck without confessing it" trope, but almost all email clients lack is Maildir. Even if you are not a technical user, you should respect the fact that proprietary formats will bite you. Look how many this guy alone used. If you use opensource, even, the mbox and mh all email, one giant file paradigm is all nice until it is corrupted. I wish more clients respected Maildir underneath, or tried to bend the truth on Windows FAT32 and NTFS ad the ; in path names limitation is a pain. https://en.wikipedia.org/wiki/Maildir#Filesystem_Compatibility_Issues https://en.wikipedia.org/wiki/Maildir#Filesystem_Compatibili... Sadly even Thunderbird has struggled to re-engineer a Maildir subsystem where it was never intended. Show me any email client devs who had the khutzpah to even dare that. https://bugzilla.mozilla.org/show_bug.cgi?id=845952 https://bugzilla.mozilla.org/show_bug.cgi?id=845952 But you have a lot of safety in spreading it across files, and you can throw dumber full text search at it, shell scripts, and a lot more flexibility over all. Sadly, some Unixisms will never escape Unix culture. As someone who has watched people screw 10+ years of email in Thunderbird n>1 times, I wish for the love of God everyone would use Maildir in the client, regardless of interface, free or not, et cetera.

ksk 10y ago
I don't agree with you. Like with anything else, less abstraction = more performance. Creating a specific/targeted way to index, store and manage email data has its benefits too. I'd hazard a guess that most proprietary formats are similar to the maildir format. Its just that the individual files are opqaue at the filesystem level. If you create thousands of tiny files then you are hoping that the file system design - which like any other design can only be optimized for specific workloads - can handle it better than a database type format specifically designed for email. Then again a generic full text search system (which probably won't even know that they're email files) over those thousands of files would have to be better than a targeted design for email data. You would miss certain optimizations like.. (making one up now) extracting and storing just the email headers in a separate region to speed up indexing and having some indirection built in to lookup that specific email.
- gary_bernhardt 10y ago
  There's nothing stopping a mail client from maintaining arbitrary indexes, caches, etc. in addition to the maildir.
  - ksk 10y ago
    Sure, every time you deviate from a targeted design you leave performance on the table. Whats acceptable to you, may not be to others.
    - gary_bernhardt 10y ago
      Then keep exactly your preferred high-performance database design, but derive its data from maildir, such that all mail is persisted in maildir first.
      - ksk 10y ago
        Yes, that would be a good way to go.
    - 616c 10y ago
      Performance doing what? Email has several operations and none of these clients are performant at scale. You know why mutt can be for me? I have a second program (isync/mbsync) sync the maildirs, a third to index it, and mutt is just for reading and sorting. When you have one monolith doing all 3 at its will all the time, you get calls from users that Thunderbird and Mail.app are janky and the computer is hosed. It is interesting as FTS came to Thunderbird and they ran the indexer all the time, until they intelligently designed to have better controls around its execution as it destroyed general usability. Mail.app is better, but I see executive running it for days and it becomes a misbehaving pile of mess. I am asking in a respectful tone and not to make light of your position, but what do you use? I want to get a better look into your view and I think this might help me understand you better, if you are willing to indulge me. UPDATE: And when I say several things at once, ironically this is not by design! Email has changed a lot since the sendmail days (and that is cutting edge with respect to many veterans here) and thus there is well-known and accepted design I can think of beyond layers of addition on clients to meet definitions and changes in protocol, routinely made without any discussion of client operation beyond standards for file structures like mbox and Maildir, even they are formal standards, I would have to check,
kartickv 10y ago
That's an implementation detail, best left to the developer of the app. What I care about is UI, speed, search, privacy, etc.

by 616c 10y ago

ksk 10y ago

I don't agree with you. Like with anything else, less abstraction = more performance. Creating a specific/targeted way to index, store and manage email data has its benefits too. I'd hazard a guess that most proprietary formats are similar to the maildir format. Its just that the individual files are opqaue at the filesystem level. If you create thousands of tiny files then you are hoping that the file system design - which like any other design can only be optimized for specific workloads - can handle it better than a database type format specifically designed for email. Then again a generic full text search system (which probably won't even know that they're email files) over those thousands of files would have to be better than a targeted design for email data. You would miss certain optimizations like.. (making one up now) extracting and storing just the email headers in a separate region to speed up indexing and having some indirection built in to lookup that specific email.

gary_bernhardt 10y ago
There's nothing stopping a mail client from maintaining arbitrary indexes, caches, etc. in addition to the maildir.
- ksk 10y ago
  Sure, every time you deviate from a targeted design you leave performance on the table. Whats acceptable to you, may not be to others.
  - gary_bernhardt 10y ago
    Then keep exactly your preferred high-performance database design, but derive its data from maildir, such that all mail is persisted in maildir first.
    - ksk 10y ago
      Yes, that would be a good way to go.
  - 616c 10y ago
    Performance doing what? Email has several operations and none of these clients are performant at scale. You know why mutt can be for me? I have a second program (isync/mbsync) sync the maildirs, a third to index it, and mutt is just for reading and sorting. When you have one monolith doing all 3 at its will all the time, you get calls from users that Thunderbird and Mail.app are janky and the computer is hosed. It is interesting as FTS came to Thunderbird and they ran the indexer all the time, until they intelligently designed to have better controls around its execution as it destroyed general usability. Mail.app is better, but I see executive running it for days and it becomes a misbehaving pile of mess. I am asking in a respectful tone and not to make light of your position, but what do you use? I want to get a better look into your view and I think this might help me understand you better, if you are willing to indulge me. UPDATE: And when I say several things at once, ironically this is not by design! Email has changed a lot since the sendmail days (and that is cutting edge with respect to many veterans here) and thus there is well-known and accepted design I can think of beyond layers of addition on clients to meet definitions and changes in protocol, routinely made without any discussion of client operation beyond standards for file structures like mbox and Maildir, even they are formal standards, I would have to check,

kartickv 10y ago

That's an implementation detail, best left to the developer of the app. What I care about is UI, speed, search, privacy, etc.