On 5/5/14, 9:06 PM, Steve Holme wrote:
> On Mon, 05 May 2014, Dionysios Kalofonos wrote:
>
>>> I also think we should try and address this for 7.38.0 - the release
>>> after next assuming you and I have the time for it ;-)
>>
>> Ok, great!
>
> I think the areas we need to look at are as follows:
>
> * Fixed libcurl FETCH API (as you suggested in Option A)
> * Change the LIST command be driven off CURLOPT_DIRLISTONLY

ok

> * Change current custom commands to be an override of LIST

I have been working a bit on this and i have introduced the function
imap_perform_custom (attached). Do you prefer that or overriding LIST?

> * Implement custom command support for FETCH
> * Implement custom command support for APPEND
>

Could you please elaborate on these? I do not understand them.

> The only thing I'm not 100% sure about in my own head is what to do with the
> following URL for example:
>
> imap://imap.example.com/INBOX
>
> Currently it will performs a LIST command, but Section 5 of RFC-5092
> suggests (if I have understood it correctly) using it to perform a SELECT or
> EXAMINE command.

Yes you are correct. And to help you out on this decision allow me to
stress the difference between the two by quoting the RFC3501:

       The EXAMINE command is identical to SELECT and returns the same
       output; however, the selected mailbox is identified as read-only.
       No changes to the permanent state of the mailbox, including
       per-user state, are permitted; in particular, EXAMINE MUST NOT
       cause messages to lose the \Recent flag.

Hence if we intend for this url to be used more freely by the client
maybe an EXAMINE is more appropriate.

>
> When we expanded IMAP last year the curl tool didn't support multiple URL
> requests using separate options (as per recently added --next) so it made
> sense for the URL to do something that would be useful to the user. As such,
> a URL including a mailbox but no FETCH or SEARCH options does make sense, at
> the time, although it can be argued that a single URL can also perform the
> same functionality. For example, if we change it to perform just a SELECT
> command then:
>
> imap://imap.exmaple.com/INBOX --next imap://imap.example.com/INBOX/;UID=1
>
> Would be the same as:
>
> imap://imap.example.com/INBOX/;UID=1
>

Using --next the client gets the response of both urls, right? Hence,
the client would get also the response of the SELECT/EXAMINE which
includes the uidvalidity, total (EXISTS), and uidnext among the rest.

> Which seems a little pointless on its own, however, it could be used to
> periodically check the UID validity of a mailbox:
>
> imap://imap.exmaple.com/INBOX;UIDVALIDITY=50

On the contrary, now the client has to issue a custom SELECT/EXAMINE
request to get the uidvalidity. Stopping at the SELECT/EXAMINE is not
that bad is it may seem.

>
> This is currently possible, but a FETCH would be issued afterwards. I.e.
> it's only possible with:
>
> imap://imap.exmaple.com/INBOX;UIDVALIDITY=50/;UID=1
>
> Which would then:
>
> * Issue the SELECT
> * Check the UID validity
> * Issue the FETCH of message 1 if the mailbox is still valid
>
> I think I've just talked myself into changing the action for /INBOX into a
> SELECT rather than being a LIST, as well, but I would be interested to know
> yours and others views on this ;-)

I agree with you i think stopping at a SELECT/EXAMINE is sufficient.

-- 
Dionysios Kalofonos

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