Paul J Stevens wrote: > > Besides, by Real Grand Idea would be to use dbmail for local storage, > > ultimately building a direct interface to it into at least one mail > > reading program. (It's not as crazy as it sounds, when one has nearly a > > gigabyte of mail lying around - like I do.) > > Well, the idea is to provide a little bit more than just local storage.
Certainly agreed. Local storage is just one possible use. ISP mail is another. And then there's LAN/corporate mail. Access protocols may vary in all these cases. IMAP is one solution that works (more or less) in all of them. It's probably optimal for ISPs; for other cases it has its own drawbacks. So separating the protocol and storage/search layers seems like the Right Way. In fact, now that I think of it, we might consider not reimplementing POP3/IMAP at all, but instead building an interface to the DB storage engine for one of the well established POP3/IMAP solutions (Cyrus, Dovecot, Courier...). But it's just a thought, which requires study before it becomes a proposal. > > And that would require a *clean* separation of functions, just Not > > Present in existing code. For example, my idea would involve a search > > and a fetch defined as functions, and separate IMAP parsing functions > > calling them. > > Makes sense to me. So we have a consensus here:) > > This may be THE critical question. If Ilja goes on with this code, then > > it's worth refactoring (especially since a rewrite might mean losing > > that). > > Perhaps even Ilja won't have any regrets if he can dump the current > codebase. However, his input, and Aaron's > as well, is critical in such a decision. And I also don't want to > alienate the current userbase. Perfectly agreed. If Ilja and Aaron join the idea, it's definitely worth a run. And my proposed name would be DbMail-ng. (As in supermount-ng). Yours, Mikhail Ramendik
