Re: RFC: More imap patch.
Date: Mon, 5 Apr 2010 22:41:12 +0200 (CEST)
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.
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.
> 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
> 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.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2010-04-05