No subject

IDLE on all its connections, and as soon as it was notified of a new
incoming message, it would disengage IDLE and immediately start
downloading that message. I believe this method caused the stalled bug
that got finally got imaplib2 canned from OfflineIMAP (imaplib2
thought it was no longer in IDLE, when in fact it was so all commands
were ignored by the server).

My planned use of IDLE is to have one session open and dedicated to
running IDLE all the time. Any updates that come in over IDLE are sent
to a threadpool which either downloads the new message or deletes the
local copy in order to stay in sync with the remote.

Personally I think this is the only way to go as it keeps a clear
separation of concerns, and keeps everything just that much simpler.
But then again, I'm biased. :)

Abstraction aside, were I building this just for myself I'd refactor
IMAP4Client into three classes: IMAP4ClientBase(basic.LineReceiver,
policies.TimeoutMixin), IMAP4ClientIDLE(IMAP4ClientBase), and
IMAP4Client(IMAP4Client). Whatever IMAP4Client and IMAP4ClientIDLE can
both use is put in IMAP4ClientBase, and the rest stays in IMAP4Client.

That, unfortunately, just forces everyone else to build their
applications my way though. Like I said, abstraction is not my strong
suite. :(

As I was typing this all out though, a possible solution occurred to
me: What if  IMAP4Client and IMAP4ClientIDLE were mixins instead? ex-
class myIDLEClient(IMAP4ClientIDLE, IMAP4ClientBase)
class myFullIMAPClient(IMAP4ClientIDLE, IMAP4Client, IMAP4ClientBase)

Thoughts?


Some questions I forgot to ask earlier: What exactly is the purpose of
a "Factory"? In some examples I've found, I saw methods that could
have gone in the Protocol subclass go instead in a ClientFactory. In
other examples there was no ClientFactory at all!
What is the exact purpose of an "Interface"?
Somewhat relatedly: As far as I can tell, the main "types" or "parts"
of a Twisted application are: reactor, Protocol, Interface (auth?),
and ClientFactory. Are there any I'm missing? And how exactly do all
these parts fit together?

Sorry for the base questions, but I've looked all over the
documentation and through the Twisted Essentials book and I can't find
a clear-cut answer to these questions and its driving me nuts!

Last question for the night (I swear!) - what kind of parsing and
dispatch system/method/technique did you have in mind to replace what
is currently in the library?

I looked over the commandDispatch method and I see what you were
talking about. But outside of using an actual parsing library like
pyparsing (which I think is disallowed in the twisted coding
guidlines, right?), or providing a static list of all possible IMAP
commands, I'm not sure what the options are.

Also, I don't follow your concern for backwards compatibility. Correct
me if I'm wrong, but method names are based upon the command that
triggers them. So even if you use a different method to parse the IMAP
command, the method names wouldn't change, right?

--=20
Dominic LoBue