On Wed, 9 Apr 2014, Dionysios Kalofonos wrote:

> > Unfortunately you are correct. Curl doen't implement the UID based
> > commands at present. The IMAP protocol is still work-in-progress to a
> > certain degree as I believe we have very few users* of and the current
> > implementation is only a year old.
> >
> > Are the UID variants preferred over the non UID versions?
>
> Ah, although it seems inconsistent at first the rfc5092 does allow a
> standard FETCH in this case, my bad, quoting the rfc

No problem...

> The <iuid> refers to an IMAP4 message Unique Identifier (UID), and it
> SHOULD be used as the <set> argument to the IMAP4 "UID FETCH"
> command.

I must admit, and possibly because I've read those rfc's far too many times
(as well as the other email protocol related ones!) that I'm a bit lost now
:(

Should the following URL be used for a UID FETCH or a plain FETCH in your
opinion?

imap://imap.example.com/INBOX/;UID=1

> > Currently all custom requests for IMAP overload the behaviour of a
> > LIST command :(
>
> If i wanted to fix this how would i go about it? I am not yet familiar
> enough with the code.

If I was you and if I was totally new to the project (and I'm assuming you
are - apologies if you are not) I would recommend:

* You clone the curl repository and build curl (if you haven't already)
* Read our coding styles and commit style documents
* Familarise yourself with the imap code in imap.c
* Look at adding query support in the URL as the first objective
* Modify the handlers to remove the PROTOPT_NOURLQUERY flag
* Take a look at imap_do() and imap_parse_url_path() in particular. We might
want to consider adding a imap_parse_url_query() function which parsese the
result and puts it into a "query" variable in the IMAP structure (see
imap.h)
* Look at the logic in imap_perform() for performing a request and perform a
SEARCH if query member is set

Once you have that working, send in your commits in one or more patch files
(I would recommend breaking tasks down into separate commits so that it
makes reviewing your changes easier as well as bisecting any problems in the
future a lot easier as well).

Meanwhile we can discuss whether curl should be performing UID based
commands if the UID is specified in the URL or not and how do we invoke the
non UID commands if we do?

For example, and I'm thinking totally off the top of my head here so please
don't take this as "the solution"...

* Specifying just the mailbox in curl terms doesn't really make much sense
for the purpose of just performing a SELECT
* As such I decided to use it to perform a LIST command, but we might want
to use it to perform a SELECT and normal FETCH with it instead
* Specifying the UID in the URL could then turn that FETCH into a UID FETCH
* Alternatively specifying the query string in the URL could perform a
SEARCH followed by a FETCH of those results
* Specifying an upload with -T (or --upload-file) performs a STORE (as it
does now)
* But specifying UID in the URL turns that into a UID STORE
* Using the -l (or --list-only) option could be a better way to perform a
LIST and that combined with -X (or --request) is then used to perform the
other commands: EXAMINE, NOOP, etc...

> Studying this issue, i also noticed that curl implements the FETCH request
as
> FETCH n BODY[...]
>
> while the rfc5092 requires a BODY.PEEK, in detail

That was a decision we made just over a year ago. We could change it to be a
PEEK but then we would need a way of performing a normal BODY which then
sets the \Seen flag. If we were to have custom requests as overrides to
their respective commands rather than as a way of performing overrides of a
LIST command then the custom request could be used to override that FETCH
behaviour.

My only worry, and I would like Daniel's and other's input here is regarding
backwards compatibility both at a curl and libcurl level!!

> I am more than happy to help.

Nice to have another pair of hands so welcome aboard ;-)

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-04-09