The following is a list of some items that I hope to include in a future 
release:

- Better support for converting a message into a structure that is based upon
the message's BODYSTRUCTURE. 

- Currently a number of IMAP Client commands are implemented using the 
'default method', which is an AUTOLOAD hack. I'd like to reduce that if 
possible to a bare minimum.

- I'd like to provide more perlish interfaces, such as the folders method 
which returns an array or a pointer to an array of folder names and which 
has no direct IMAP counterpart. For example, a 'since' method could be 
written to implement the SEARCH SINCE syntax. It would be nice if eventually 
you didn't have to reference RFC2060 to use this module. ** Many of these methods
have been implemented since this was first written. ** 

- I'd like to see this module certified for more OS's and more IMAP servers. 
This is (hopefully) just a matter of testing; the code should already be 
compatible with the IMAP servers that are out there and with any OS that 
allows the IO::Socket module to work. ** A number of platforms have been added
to the list of tested platforms since this was first written. Please contact 
David.Kernen@erols.com if you have any to add.

- Support for older/other versions of IMAP. Currently only RFC2060 is 
explicitly supported, although thanks to the 'default method' (implemented 
via an AUTOLOAD hack) virtually any IMAP command is supported, even 
proprietary commands, X- extensions, and so forth. But not necessarily other 
authentication mechanisms... :-( (NOTE: the AUTHENTICATE method 
partially addresses this issue.)

- Support for other authentication mechanisms, such as NTLM. (NOTE: Ditto 
above in re the recent AUTHENTICATE method.)

- Support for a "Peek" mode, which will cause the client to use "peeking" commands (i.e. commands that
do not set the "\Seen" flag) wherever possible and appropriate. The parse_headers method already does its 
thing in peek mode; message_string does not. (Of course if you've just gobbled up a whole message into a
string, then that's more than just a peek, isn't it?) Anyway, I'd like to create a new parameter ("Peek?")
that, if set, will force Mail::IMAPClient to either peek or not peek.

- Support for piping output from (some?) imap commands directly to a thingy of some sort
(perhaps a coderef, a filehandle, or both). 

- A message_to_file method, which would be much like the append_from_file method except it would be the 
opposite. (If you can parse IMAP output then you should be able to parse the previous sentence. ;-)

- Your thingy here!!! Send me your request, and I'll do it in the order of ( $popularity/$difficulty ).

