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 protected]
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "Junk"
imap://[email protected]/INBOX
* LIST (\HasNoChildren) "/" "INBOX"
Better suited when working with UIDs
imap://[email protected]
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "Junk"
imap://[email protected]/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
From cdc2a3a21a4b656f482cb76b4cd4a1d38484b3be Mon Sep 17 00:00:00 2001
From: Dionysios Kalofonos <[email protected]>
Date: Fri, 11 Apr 2014 18:25:39 +0300
Subject: [PATCH] Introduces references to RFC5092.
---
docs/examples/imap-fetch.c | 2 +-
docs/examples/imap-multi.c | 2 +-
docs/examples/imap-ssl.c | 5 +++--
docs/examples/imap-tls.c | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/docs/examples/imap-fetch.c b/docs/examples/imap-fetch.c
index 831d0dc..1fa5566 100644
--- a/docs/examples/imap-fetch.c
+++ b/docs/examples/imap-fetch.c
@@ -39,7 +39,7 @@ int main(void)
curl_easy_setopt(curl, CURLOPT_USERNAME, "user");
curl_easy_setopt(curl, CURLOPT_PASSWORD, "secret");
- /* This will fetch message 1 from the user's inbox */
+ /* This will fetch message 1 from the user's inbox (see RFC5092, s. 6). */
curl_easy_setopt(curl, CURLOPT_URL,
"imap://imap.example.com/INBOX/;UID=1");
/* Perform the fetch */
diff --git a/docs/examples/imap-multi.c b/docs/examples/imap-multi.c
index 601205a..e0fc783 100644
--- a/docs/examples/imap-multi.c
+++ b/docs/examples/imap-multi.c
@@ -69,7 +69,7 @@ int main(void)
curl_easy_setopt(curl, CURLOPT_USERNAME, "user");
curl_easy_setopt(curl, CURLOPT_PASSWORD, "secret");
- /* This will fetch message 1 from the user's inbox */
+ /* This will fetch message 1 from the user's inbox (see RFC5092, s. 6). */
curl_easy_setopt(curl, CURLOPT_URL, "imap://imap.example.com/INBOX/;UID=1");
/* Tell the multi stack about our easy handle */
diff --git a/docs/examples/imap-ssl.c b/docs/examples/imap-ssl.c
index e42ff39..98bba12 100644
--- a/docs/examples/imap-ssl.c
+++ b/docs/examples/imap-ssl.c
@@ -40,8 +40,9 @@ int main(void)
curl_easy_setopt(curl, CURLOPT_USERNAME, "user");
curl_easy_setopt(curl, CURLOPT_PASSWORD, "secret");
- /* This will fetch message 1 from the user's inbox. Note the use of
- * imaps:// rather than imap:// to request a SSL based connection. */
+ /* This will fetch message 1 from the user's inbox (see RFC5092, s. 6).
+ * Note the use of imaps:// rather than imap:// to request a SSL based
+ * connection. */
curl_easy_setopt(curl, CURLOPT_URL,
"imaps://imap.example.com/INBOX/;UID=1");
/* If you want to connect to a site who isn't using a certificate that is
diff --git a/docs/examples/imap-tls.c b/docs/examples/imap-tls.c
index c439864..a8374c6 100644
--- a/docs/examples/imap-tls.c
+++ b/docs/examples/imap-tls.c
@@ -40,7 +40,7 @@ int main(void)
curl_easy_setopt(curl, CURLOPT_USERNAME, "user");
curl_easy_setopt(curl, CURLOPT_PASSWORD, "secret");
- /* This will fetch message 1 from the user's inbox */
+ /* This will fetch message 1 from the user's inbox (see RFC5092, s. 6). */
curl_easy_setopt(curl, CURLOPT_URL,
"imap://imap.example.com/INBOX/;UID=1");
/* In this example, we'll start with a plain text connection, and upgrade
--
1.8.5.2 (Apple Git-48)
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
