Maxim Khitrov <max@mxcrypt.com> wrote:
I tend to think one of the larger missing pieces of imap4lib is the lack of a higher-level interface. I've used imap4lib for a couple of projects, and I think that if I hadn't already had the experience of implementing my own IMAP server in Python, I wouldn't have done that; I'd have used a package like getmail instead. There's a lot of experience with IMAP necessary to use imap4lib.
True, but that's the case with all low-level interfaces. Having used imaplib for a while before deciding to write a replacement, I do think that building a higher-level interface using my library is significantly easier.
I'm not certain if that interface should be part of the library or a separate module, similar to the relationship between zlib and gzip. I think the latter makes more sense, because any serious IMAP4 client will still need to descend to the protocol level.
There are lots of folks who just need to connect to an IMAP account, and do something with their mail. Many many fewer need to write a serious IMAP4 client. That's the big problem with the current imap4lib; it just doesn't work for most of the use cases, because it's too low-level. So it doesn't get much use -- more's the pity.
Looking at your example.py, that still seems to be the case. One thing you might consider is implementing a subclass of "mailbox.Mailbox" which provides that missing higher-level interface to IMAP4.
I've never used the mailbox module before. It looks like it is aimed primarily at working with local mail stores, no? I'm not sure if that's the right interface to use over the network, but I understand your point.
I'll try to write another class on top of my library with a much simpler API for navigating through the mailbox hierarchy and working with messages. Will upload it to the repository when it's ready.
Cool! Looking forward to it. I'd still suggest making it a subclass of mailbox.Mailbox, btw. PEP 20: "There should be one -- and preferably only one -- obvious way to do it." Bill