On 5/6/2014 6:53 PM, Steve Holme wrote:
> On Tue, 06 May 2014, Ray Satiro wrote:
>
>>> 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
>>> * Change current custom commands to be an override of LIST
>>> * Implement custom command support for FETCH
>>> * Implement custom command support for APPEND
>> Is any of that going to affect parsing custom results from the header
>> field? * ABC {123}\r\n the following 123 bytes aren't returned in the
>> body so right now for example I have code like this to retrieve all
>> subjects via FETCH that match "some subject" (curl 7.34.0):
> I think the short answer is no it shouldn't alter the output...
>
> However, if I've understood you correctly you seem to be parsing the results
> so you can then go off and FETCH part of those messages to know what size
> they are.
>
> If that is case then the longer answer is (and I hope this is correct as
> I've spent the last hour authoring this email and now getting quite tired!)
>
> RFC-5092 recommends using the following URL syntax for performing some of
> what you are trying to do. For example:
>
> imaps://user:pass_at_imap.gmail.com:993/%5BGmail%5D%2FAll%20Mail?SUBJECT%20some
> %20subject
>
> The RFC shows an example that issues a "SEARCH SUBJECT some subject"
> followed by an automatic FETCH of the messages in that result set.

Thank you for your time. The code looks for an exact phrase in a subject
and all I want is the subject. SEARCH SUBJECT as far as I know can't do
that for Gmail. If I SEARCH SUBJECT for "foo bar" or even \"\\\"foo
bar\\\"\"" I will still get search results that include "bar foo". Since
I'm using Gmail I've found it's easier for me to use their imap
extension X-GM-RAW [1] for searching since I can search using most of
the same options as I can in the gmail search box [2]. in:anywhere
doesn't seem to work for example since I guess there is no mapping for
it to multiple mailbox search so I switch to mailbox All Mail instead.

[1]:
https://developers.google.com/gmail/imap_extensions#extension_of_the_search_command_x-gm-raw
[2]: https://support.google.com/mail/answer/7190?hl=en

> I have added support for this URL syntax in the upcoming 7.37.0 release -
> however it currently only performs the SEARCH and not the FETCH.
>
> As such can I ask:
>
> A) Is the functionality I've added in v7.37.0 going to help at all?
> B) Would it be more useful to automatically perform a FETCH of those
> messages returned by the SEARCH results as suggested by the RFC?
>
> You then seems to be parsing the FETCH data from a custom request because:
>
> 1) You want to know the message size from "* ABC {123}" which isn't output
> in the current FETCH handler
> 2) The FETCH command with an alternative set of arguments, such a PEEK, can
> only be performed via a custom request
> 3) The custom request currently overrides a LIST type command rather a FETCH

I'll probably keep issuing custom commands because of my requirements.
With a regular SEARCH I can't get exactly what I want but that's my
problem. If you're going to make changes to FETCH may I suggest it would
be helpful if a result even of a custom FETCH were recognized and didn't
have to be parsed from the header (which maybe is what you are thinking
about implementing?). For example "FETCH 1 BODY[TEXT]" the actual bytes
returned would be in the body (what curl recognizes as the body).

> Even if we didn't implement B but 1, 2 and 3 were fixed by what I suggested
> in my previous email, then I think your code could be a little simpler if
> you wanted to change it, and I appreciate this is a very bold statement to
> make prior to making the changes, but I wouldn't expect you to have to
> change your code with how you are using libcurl:
>
> * The FETCH custom request would be handled internally in the FETCH handler
> * The FETCH handler will be fixed to return the extra data that you are
> currently getting via LIST handler
>
> Hopefully what I have written there is correct and more importantly doesn't
> change - however, it would be great if you are available and would be
> willing to test the code in the repository during the implementation of this
> ;-)

Yes I'd be willing to try out the code. I don't use IMAP often enough to
offer a specific direction either way but I was asking so if my code
breaks --which is fine, I'll fix it-- I know and I'll have some lead
time to get in front of it before a release.

On 5/7/2014 10:05 AM, Dionysios Kalofonos wrote:
> I think the opposite will be the case...
>
> Now the CURLOPT_CUSTOMREQUEST does not return any continuation data as
> it overrides the LIST handler. Hence, it returns only the first part
> of the response up to the first \r\n. However, if we fix it, it will
> be handled by the FETCH handler, which will return the whole response:
>
> * ABC {123}\r\nTHE 123 BYTES and the closing ')'
>
> So yes the 123 bytes will be part of the response.
>

Ok, I'll mark this down as too soon to tell :)

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