[Twisted-Python] POP3 improvements

Christopher Armstrong radix at twistedmatrix.com
Tue Dec 31 00:47:24 EST 2002


On Tue, Dec 31, 2002 at 12:57:06PM +1100, Andrew Bennetts wrote:
> On Mon, Dec 30, 2002 at 01:09:52PM -0500, Abe Fettig wrote:
> > On Mon, 2002-12-30 at 11:48, Itamar Shtull-Trauring wrote:
> > > > supplied a StringIO is used.  When the server is finished sending the
> > > > response, handle_COMMANDNAME is called, passing back the file object
> > > > containing the downloaded response.
> > > 
> > > Instead of calling handle_COMMANDNAME, why not return a Deferred of the
> > > success?
> > 
> > Based on other Twisted protocol handlers I thought that the preferred
> > way to handle events in protocols was to create methods that get called
> > in response to events.  That way you create a class that inherits from
> > POP3Client, and override the methods for events you want to handle. 
> > Being able use classes and inheritance this way is one of the things I
> > really like about Twisted.
> 
> It depends; if the event is in response to a request, e.g. LIST, it makes
> sense to return a Deferred that will receive a list of available messages.
> FTPClient works this way, and is very convenient -- an FTPClient user can
> queue commands (like LIST, RETR, etc), and as the server responds, the
> Deferreds will fire... and there's no confusion if you issue multiple LIST
> commands in different directories, whereas a handle_LIST callback doesn't
> have the same advantage.
> 
> In your case, I'd recommend Deferreds.
> 
> If you're writing a server that waits for incoming events, then a
> handle_COMMANDNAME scheme would make good sense.

Nah, handle_FOO is useful outside of just servers (see IRCClient,
which I'll mention again in a second). It may be good to separate it
into two layers, the higher-level one returning Deferreds, which are
triggered from handle_FOO methods. This is especially useful if you
may have to wait for many low-level protocol messages before you have
the full response, but the handle_FOO idiom is nice, in general, as a
way of breaking up your protocol parsing into separate methods.

The one other place where I thought this might be useful is in
IRCClient. IRC commands often result in several messages in response
-- something like list, or whois, for example. If we wanted to
abstract this interface, we could have a "list" method that returned a
Deferred that didn't trigger until *all* the list lines have been
received.

So, as an _implementation_ strategy, the "handle_FOO" methods are
great when the mapping of message-level request to message-level
response is 1:many, and for interfaces, Deferreds are great.

-- 
 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |          Release Manager,  Twisted Project
---------+     http://twistedmatrix.com/users/radix.twistd/




More information about the Twisted-Python mailing list