On 4/10/14, 12:09 AM, Steve Holme wrote:
> On Wed, 9 Apr 2014, Dionysios Kalofonos wrote:
>
> [...]
>
> Should the following URL be used for a UID FETCH or a plain FETCH in your
> opinion?
>
> imap://imap.example.com/INBOX/;UID=1

I vote for plain FETCH since the RFC allows it. I like the simplicity
and consistency of the CURLOPT_URL API in that it uses only the plain
methods.

A UID FETCH might have been more appropriate for the sole purpose that
the URL says UID=1, hence the user does not need to recall that SHOULD
word in the spec allowing plain FETCHes. But i think a little bit of
documentation in the imap fetch examples will suffice. Perhaps something
like the one attached?

Moreover, i cannot convince myself that is worth reshaping and
complicating the CURLOPT_URL. If a client has the need for UIDs then it
must be doing some sort of synchronisation with an imap server, hence,
that client also cares about performance and bandwidth costs.
Additionally, we have to consider the loose wording of the RFC5092 and
the room that it leaves to the implementation of the spec to bundle
requests. I believe that even if the CURLOPT_URL was making UID based
requests, the client that does need UIDs would choose to use the
CURLOPT_CUSTOMREQUEST for the finer control over the communication.

Also if i understand correctly, the CURLOPT_CUSTOMREQUEST is exposed in
the curl tool through the -X, --request <command>. Hence, a user of the
curl tool will not be deprived of a UID based workflow when that is
supported only through the CURLOPT_CUSTOMREQUEST.

To summarise i suggest that the CURLOPT_URL remains simple and handy,
using only plain commands, and that the UID variants are supported
through the CURLOPT_CUSTOMREQUEST.

This is a very difficult question to answer :), what do you think?

>
> 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:
> [...]

Yes i am new. Thank you.

> * Specifying just the mailbox in curl terms doesn't really make much sense
> for the purpose of just performing a SELECT

If we pursue the UID route, then this might also be affected. The SELECT
command returns the UIDValidity, EXISTS, and UIDNext values all of which
are very important when working with UIDs.

Currently,

imap://email@imap.example.com
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "Junk"

imap://email@imap.example.com/INBOX
* LIST (\HasNoChildren) "/" "INBOX"

Better suited when working with UIDs

imap://email@imap.example.com
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "Junk"

imap://email@imap.example.com/INBOX
* OK [UIDVALIDITY 616963558] UIDs valid.
* 75 EXISTS
* OK [UIDNEXT 8315] Predicted next UID.
...
* LIST (\HasNoChildren) "/" "INBOX"

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

I second the SEARCH-FETCH combination, and in particular the
SEARCH-FETCH ALL one. The benefits are numerous, a) exposes the FETCH
ALL, b) part of the returned data are UIDs which can then be used for a
UID FETCH BODY, and c) it always fetches the subset of messages returned
by the search.

This is a useful approach for implementing the SEARCH even outside the
UID context.

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

I like the -l/-X combination. This works nicely with the SELECT notes above.

Kind regards,

-- 
Dionysios Kalofonos

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html