3 ms·

As far as I can tell from playing with many of them: - Almost all (open source and proprietary) prefer mbox-style - If not mbox, then it is monolithic file pe

by 616c 10y ago

As far as I can tell from playing with many of them: - Almost all (open source and proprietary) prefer mbox-style - If not mbox, then it is monolithic file per folder, very few if any store email per file like maildir, despite it having many benefits [0] (if you are smarter than Bernstein on such things, please do write on these things; no one gives a shit to explain email out because it is not sexy) - The index system always stores data separate of the email store; I have not seen a counter example, perhaps for Outlook, which I presume uses the Windows/OSX OS-level indexing - To get back to my point re generic FTS, there it is, keep the OS ones so people can search in one place (I use recoll and notmuch for email specifically; it's annoying) - What optimizations are there for indexing beyond header info? Again, good FTS systems can be extended (for what I define as good)[1] I do not mean to criticize your points, but I do support work and all of these clients do good for non-technical users, but are ticking times bombs that shit themslves and require resyncing all data when they corrupt massive multi-gig files, let alone re-indexing it all. Using them is one thing, having to fix them is what informs my opinions on this and why I sync to maildirs, use mutt-kz, and webmail depending on mood and time. [0] https://cr.yp.to/proto/maildir.html https://cr.yp.to/proto/maildir.html [1] https://bitbucket.org/medoc/recoll/wiki/IndexMailHeader https://bitbucket.org/medoc/recoll/wiki/IndexMailHeader apparently they have improved, perhaps I shall ditch notmuch out of notmuch discipline for email! Haha

ksk 10y ago
Well you're right that we can have a generic FTS system with a general OS based search with specific handlers for mailbox types. I guess you're trying to say that the file formats have become too complex where the clients themselves can't implement them bug-free. About that, perhaps another way to tackle that is not to go back to a more "primitive" format but to improve the quality of email clients. Personally, I never have IT problems, so I can't comment on the support burden. But I agree with you that if I had to re-prioritize, then reducing the support costs by trading performance and going back to a simpler format is probably worth it.

by 616c 10y ago

ksk 10y ago

Well you're right that we can have a generic FTS system with a general OS based search with specific handlers for mailbox types. I guess you're trying to say that the file formats have become too complex where the clients themselves can't implement them bug-free. About that, perhaps another way to tackle that is not to go back to a more "primitive" format but to improve the quality of email clients. Personally, I never have IT problems, so I can't comment on the support burden. But I agree with you that if I had to re-prioritize, then reducing the support costs by trading performance and going back to a simpler format is probably worth it.