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:[email protected]: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
