> Date: Tue, 4 May 2010 12:03:19 -0700 (PDT) > From: Mark Crispin <mrc...@panda.com> > ... > A better implementation would use an index file that maps between a UID > and a device/inode number of the file. To open and synchronize, you > stat() all the files and then correlate that with the index to build a > map. This would also identify newly-added and expunged messages.
i'll see if i can break stiction on a real API and real indexing for NMH. > ... > In my opinion, it's better to use data formats designed for the task at > hand, rather than ever-escalating steps to get legacy formats to do what > they were never designed nor intended to do. of course. but my primary mail interface is emacs mh-e and i'm not going to abandon it, nor the many filters and cronjobs and tools i've based on MH, just to support my secondary need to open attachment-containing messages in an IMAP client. i fully understand that i do not represent a growing segment of the mail market. as before, i'm thankful that uw-imap supports MH at all. > > these days almost nobody still accesses the system mailbox by NFS, nor > > access user mailboxes on NFS from more than one client at the same time. > > So the world today has finally accepted my advice from 20+ years ago. indirectly. NFS isn't a growing market segment. most new mailboxes are IMAP-only and there are fewer and fewer accessors of /var/mail/$username (or even UNIX systems containing such files) every year. > I'm surprised, though; since "do everything via NFS" was the SUN corporate > religion (maybe Oracle has disestablished it). I recognized the absurdity > of layering a NAS (IMAP) on top of a NAS (NFS) early on, but SUN (and IBM) > insisted for a long time that the right way to do IMAP was to have a > cluster of IMAP servers consumeing an NFS server. whatever sold the most iron was the corporate mantra of that moment. the people who say "just use Exchange" today are cut from that same cloth. > > so, dovecot's assumptions are pretty reasonable. compile-time options > > in uw-imapd that changed its assumptions in this way would be popular. > > UW IMAP is a dead project. If I ever do anything like that, it would be > in Panda IMAP. yes, that's a separate problem. i may try to add MH support to Dovecot so that i won't have to maintain a fork of the uw-imap abandonware nor use a non-open codebase (Panda). in the shorter term i need to consider whether to add indexing and a real API to NMH so that any of this becomes possible. _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
