Le duodi 22 thermidor, an CCXIV, Aaron Schrab a écrit : > It's not a text-mode client, or a client at all, but the ximapd project > seems to be aiming for many of the features that you were talking about. > > http://projects.netlab.jp/ximapd/ I would go and have a look at it if I could. Alas, yesterday, all I got was an error banner, and today the connection timeouts. > I think doing this in an IMAP server is a better way to go about it > anyway, since it allows you to use any MUA that supports IMAP. That way > you can use an MUA that makes it easy to read large quantities of mail > (like mutt) for most of your mail, but use a GUI client for those few > messages that actually benefit from more complex HTML. Doing part of the work in an external server is indeed an idea to consider. But part of the work is user interface, so some user agent support is necessary. Furthermore, I am not sure whether IMAP is expressive enough to allow to build virtual folders in a clean way. Le tridi 23 thermidor, an CCXIV, Kyle Wheeler a écrit : > That depends on whether you are optimizing your mailstore for > mail(dir) storage, or whether you are optimizing it for > general-purpose access. A dedicated mailstore can be configured to > deal with this problem. As I said, changing the filesystem is often not an option. For example, I am right now running Mutt on a school's login server, with hundreds of accounts. I am obviously not root on it, and I do not think the sysadmin would change its whole system setup just for me. Nor would he be happy if I started eating one tenth of the partition's inodes for my mail. This list is about a mail user agent, not a mail server, so the common case here is a general-purpose system, and not a dedicated optimized mailstore system. > Concurrent modification is one problem that it addresses, yes. There > are also major benefits for serial modification; for example, flagging > a message: in something like mbox, that could require rewriting the > entire mailbox. And that does not happen on read-only spool. Which brings me back to what I just said: maildir is of no much use on read-only spools. > Additionally, mbox has built-in inefficiencies, for > example, trying to read the 1000th message of an mbox requires first > reading through all previous 999 messages (searching for "From " > lines) in order to find where the 1000th message begins. The point you are missing is that there is no such thing as "the 1000th message". There is no unique order for mail messages; mailbox insertion time, which is the only order maildir can do better than mbox, is just one of the possible orders. For any other order, it is necessary to read the headers of the whole spool. > Actually, I know a great deal about databases. > > But if you choose not to believe me It is not that I do not believe you, it is that I could refute most of the arguments in your article. Here is not the place to do so, but if you are interested in what I have to say, I can write it in private. But there is a fundamental flaw in your "do not store mails in a database, store them in the filesystem" position: the filesystem itself is a database. It is a limited database, which enables it to have a much simpler interface, but the rest is just the same. In particular, performance and reliability are not better. Furthermore, this simpler API is not fully suited to storing mails. In the maildir specification, I see 2,5+ kilobytes of text dedicated to "How are unique names created?", which is only necessary because the filesystem requires an unique string key for its elements, while there is no such thing as a unique string identifier (reliably unique) for mails. > | Database connections are expensive in terms of time and > | processing power; it is always faster to deliver static pages. That is true, but the problem is not in the database, it is in the glue that ties the database to a network connection. To make it short, the reason dynamic pages from databases are slow is that each time the server must parse the PHP script doing the database queries. There are practical reasons to store mails in the filesystems: on nowadays Unix-style operating systems, the filesystem is an in-kernel database server, which allows it to use much shorter code paths than userland database servers. But they are not fundamental reasons: they do not apply to all operating systems of all times. And most of all, they are reasons relevant for high-load mail servers that do not care about the mutual relations between mails. For the local spool of a mail user agent, matters are completely different. And since we are not discussing about high-load mail servers but about a particular mail user agent, I believe that this arc of discussion should be closed, at least on this list. Le tridi 23 thermidor, an CCXIV, Michael Tatge a écrit : > No, you can match threads with any pattern. ~(~s foo) for example, or > the standard ~(~P) which will match any thread you participated in. Le tridi 23 thermidor, an CCXIV, Nicolas Rachinsky a écrit : > Ups, the threadcomplete patch should probably have been moved to > the old stuff section. There is an patch which supercedes my > threadcomplete patch called patch-1.5.6+20040904.tg.mutt-thread.3 > (here). But I do not have a link to the current version, I use the > one from the FreeBSD port. > > With that you you can match threads containing mails matching > arbitrary patterns. That seems perfect. I will quickly upgrade mutt and give it a try. Le quartidi 24 thermidor, an CCXIV, Thomas Roessler a écrit : > (I.e., basically, this strikes me as something that should go > in.) And it did. \o/ Regards, -- Nicolas George
Attachment:
signature.asc
Description: Digital signature