>> Weeeelll ... I think, sadly, that to really make things like IMAP a win >> we need to abstract out things a bit more. > >that sounds right. however, i'm not sure if you're saying that >abstracting out the POSIX stuff so that it can also handle Maildir is >not a good first correctness-preserving transformation that would set us >up well for a second such transformation once IMAP's semantics and >impedance are better understood, or, if you think there's no point in >doing it in two steps, and we should understand everything before we do >anything. can you elaborate?
I guess I'm saying I don't think abstracting out the POSIX filehandling stuff to also support Maildir is worth it as a first step, because I think an IMAP-friendly API is going to be such a huge change that we should focus on that. To me, there are two BIG API changes that should be done in nmh. The first is message parsing; no program should ever have to call m_getfld() again, there should be a common set of routines that you call to get out headers, MIME part information, etc etc. You probably want to integrate that with the format engine so the list of "interesting" headers can be filled in at that time. This is what I've referred to as "full MIME parsing". The second is how to access mailboxes & messages; in theory you'd think this is simple, and for Maildir we could probably get away with only a few small changes. But once you throw in IMAP you really want to handle it completely differently. A lot of message parsing gets done by the IMAP server itself, so if you design the previous API properly hopefully you can get a win there as well. So I've got some relatively concrete ideas for the first one; the second one I've got some vague notions. --Ken -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
