On 04/05/2010 01:41 PM, Daniel Stenberg wrote:
> On Mon, 5 Apr 2010, Ben Greear wrote:
>
>>> That is not a good idea. It proves it's not done right and that it
>>> won't be multi-interface friendly enough. Why does imap need to call it?
>>
>> I am sure I'm not doing it right..but I'm having a hell of a time
>> figuring out the right way to do it.
>>
>> Here is one scenario: You request 3 email, which comes to around 1500
>> bytes total. The first two, and most of the third end up in the cache
>> in that callback, but an extra 60 or so bytes must be downloaded.
>
> Easy: libcurl only gets one resource per request, so you'd call it three
> times to get three mails.

Ahh, so you don't want to support something like this?

imap://tester:passwd_at_mail.candelatech.com/INBOX/;uid=1:3

> Considering more than one file then enters the "FTP wildcard" concept
> area, but it would still technically be made by doing multiple
> individual requests internally even if you can hide that as looking like
> one big request from the outside the way the FTP wildcard patch does.

I don't think I'll be writing such logic, but I will remove
the current support in my patch for multiple email if you prefer
that.

>> My hack of doing the transfer works, but seems like some part of
>> pingpong or some other logic would do that Transfer logic.
>
> The pingpong logic is just a set of generic functions to handle
> commands<->responses between a client and server.
>
>> What logic *should* call that Transfer in this case?
>
> The "DO" phase should setup up everything and issue the necessary
> transfer command(s), the TRANSFER phase should do the actual transfer
> and DONE is then done after the transfer to do what needs to be done
> after an individual transfer.

Ok, so after we either download the complete thing in pp->cache
OR set up the transfer with Curl_setup_transfer,
we always call: state(conn, IMAP_STOP)
in the fetch_body response, and then some part of the pingpong
statemachine (or something else?) will cause the Transfer to
happen?

>> Ok, what if I get the results of a search, and it's something like:
>>
>> * SEARCH [25k of data]
>> D OK Search Completed
>>
>> As far as I can tell, there is no limit on the amount of data after
>> the SEARCH string.
>>
>> How is pingpong going to deal with this?
>
> Since pingpong won't deal with that, I can only imagine that we need to
> consider the search results to be the transfer here, so DO would issue
> the search command and the TRANSFER would receive the results.

We need to watch for the response result line (first line that doesn't
start with "* SEARCH"

How can we get the TRANSFER logic to feed imap.c the data to inspect
it for this? In fact, we need to intercept it entirely so that we don't
write the 'OK' line to the write-callback method.

Thanks,
Ben

-- 
Ben Greear <greearb_at_candelatech.com>
Candela Technologies Inc  http://www.candelatech.com
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html