Hi everyone,

I'm working at a semi-large telco company, where we use libcurl for
outbound HTTP(S) and SMTP requests due to its good scalability and
ability to work with custom low-level socket frameworks (thanks for
that!). Now there is demand for interworking with IMAP servers. The
first assessment was quite optimistic as "CURL does IMAP, right?", but
then we came to realize the IMAP support in libcurl is quite limited.

Nevertheless, after looking at the alternatives and associated
development costs, I've settled on trying to use CURL anyway and
enhancing the current level of IMAP support in it. I'm writting to the
list to validate the approaches I've taken and align what I'm doing
with you, so that my patch is more correct and could get accepted back
to the mainline.

The application will need to:
  * Read individual messages or their parts (FETCH)
  * Store a new message to the server (APPEND)
  * Create and delete mailboxes (CREATE, DELETE)
  * Test for existence of a folder (LIST)
  * Set flags on a message (STORE)
  * Change folder user permissions (SETACL)
  * Remove messages flagged as erased from a folder (EXPUNGE)
...which is quite a lot of features. But they can be divided into 3
groups and dealt with fairly quickly:

1/ For reading, the natural way is to just improve the handling of
IMAP URLs to achieve full (or at least sufficient) compliance with RFC
5092 (IMAP URI Scheme). This is otherwise more or less implemented.

2/ APPENDing would require a similar interface like FETCH, but the
other way around, uploading instead of downloading. The library
already has uploading capabilities, shouldn't be too hard either.

3/ The other commands need some new design. My idea is to use
CURLOPT_CUSTOMREQUEST, where the content would be a command name
string, like "LIST" or "CREATE". The URL would then contain the
parameters of the command instead of a path to the message to fetch.
E.g., for "CREATE" or "EXPUNGE", the URL would be just a path of a
folder.
For commands like STORE, a custom URL format like
"INBOX/;UID=123?set=%5CFlagged" would be introduced. Results from LIST
etc. would be returned as a body to the client for further parsing
(the header stream is unfortunately already used for unfiltered
ping-pong replies). Parsing of such replies would be up to the client
(library user) - one has to draw the line somewhere.

The currently SELECTed mailbox for a connection would be naturally
cached to avoid the performance penalty of re-opening the mailbox for
each (mailbox-relative) request.

A prototype with the overall design as described above seemed to come
to life quite nicely. Of course there was a lot of cleanup or
refactoring (there are still contextual and literal references to FTP
in imap.c), but almost exclusively isolated to imap.{c,h}.

So, does anyone have any comments or advices about all this stuff?
Would you be fine with improving the IMAP protocol handler like this?

Thank you,
Jiri
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-11-19