From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Add Maildir support to RMAIL Date: Mon, 26 Jul 2021 09:08:36 +0300 Message-ID: References: <83h7giwjtb.fsf@gnu.org> <1627225069.25819@bluehome.net> <87wnpdhm0s.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27717"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.7+183 (3d24855) (2021-05-28) Cc: emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 26 09:11:41 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m7um5-00073w-G3 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 09:11:41 +0200 Original-Received: from localhost ([::1]:33214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7um4-0003EH-GN for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Jul 2021 03:11:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7ui8-0006mJ-Gq for emacs-devel@gnu.org; Mon, 26 Jul 2021 03:07:36 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:54311) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7ui6-0001yO-FZ for emacs-devel@gnu.org; Mon, 26 Jul 2021 03:07:36 -0400 Original-Received: from localhost ([::ffff:41.202.241.46]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000057F55.0000000060FE5F15.00005EBE; Mon, 26 Jul 2021 00:07:00 -0700 Mail-Followup-To: Tim Cross , emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <87wnpdhm0s.fsf@gmail.com> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271635 Archived-At: * Tim Cross [2021-07-26 05:01]: > How your email provider (e.g. google) stores messages is irrelevant. You > retrieve messages from your provider via imap (or possibly pop3), which > is a protocol that sits at a higher level than storage - it does not > know or care about how the messages are stored. It simply retrieves the > message and passes it through to your imap client. That is right in most cases. Though MTA on the remote server may store messages in Maildir format. That allows also tools like scp or rsync to be used to move remote Maildirs to local computer. > These days, I use mu4e and mbsync. My messages are stored in maildir > format and I have the power of 'mu' to search/manipulate them and the > ease of mu4e for reading. The `mu' indexer is great, and `mu4e' is using the `mu' indexer, and not directly Maildir format. it is "via" that helps in finding emails like a search engine, but does not really help handling and reading and manipulating Maildir format. > The nice thing about mu4e is that it uses Emacs' standard message > mode for composing messages and Gnus' for displaying/rendering > messages (but without the overhead/confusion of a Gnus > interface). One bad thing is that mu4e cannot handle number of Maildirs when it comes to 50000 conversations, it will never complete the list of Maildirs. I have alerted author longer time ago, though it does not help. > Another 'simple' mail interface which is quite popular is 'notmuch', > which I've not used, but I believe is based on similar principals > i.e. small utilities which are combined together with a nice > interface wrapper written in Emacs lisp. It is way slower on my x86_64 GNU/Linux system than `mu', or it may never even finish the indexing process. It needs probably 5 times longer time to index 50000+ Maildirs than `mu' indexer. > The only time when you really need to worry about what storage format > your email client uses is when it comes to sorting out backups or > perhaps fixing data corruption. The maildir architecture became popular > because mbox was seen as a bit inefficient and fragile (large files > where any corruption make all messages unavailable) or when using > multiple clients. Nothing changed in that regard. Mbox system did not improve over the Maildir system. Using maildir format by D.J. Bernstein http://cr.yp.to/proto/maildir.html Quote: Why should I use maildir? Two words: no locks. An MUA can read and delete messages while new mail is being delivered: each message is stored in a separate file with a unique name, so it isn't affected by operations on other messages. An MUA doesn't have to worry about partially delivered mail: each message is safely written to disk in the tmp subdirectory before it is moved to new. The maildir format is reliable even over NFS. > I think it is a bad idea to try and share the same data across clients. > I've found that even when a client claims to use maildir format, there > can be some subtle differences in implementation which can affect how > reliable the storage is. Various software is free by the Maildir specification to expand on it, but Maildir still remains readable and manageable by Maildir clients. If you have particular software that is not compatible to Maildir but is expected to be, let me know. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/