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.

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

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
;-)

> Unrelated- Thanks for your work on VS project files. Haven't tried them
> yet but I could use them.

Thank you. Although I've still need to automatically generate them via
makefile.am - ideally before the release of 7.37.0 :(

Kind Regards

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