On Mon, 19 Nov 2012, Jiøí Hru¹ka wrote:

> 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.

Sounds great and thanks for doing this work! I'll certainly try to add my
views and comments on your suggestions and I promise to review your upcoming
patches too!

I would recommend that you familiarize yourself with the test suite too at the
same time while doing your changes, so that you can add tests to verify what
you do and that old stuff keep working.

> 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.

Yeps, shouldn't be too hard.

> 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.

Parsing of these replies seem to be the client's job, yes.

I'm not convinced we should use a different URL syntax for different
CUSTOMTREQUESTs though. We have not used that concept for any other protocol
and it would introduce a new paradigm that is a bit tricky to follow.

If a command cannot use the same generic format for the URL, I think we should
consider enabling that command and its data in another way. We also have the
CURLOPT_QUOTE style of providing commands which gives the client a very large
freedom do send in bascially whichever command it likes.

Possibly we can start with the simpler cases and then we can discuss the more
complicated cases when you have something to show that you like and think
could work?

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-11-21