On 04/06/2010 02:30 PM, Daniel Stenberg wrote:
> On Tue, 6 Apr 2010, Ben Greear wrote:

>> With my current logic, specifically calling the Transfer is what makes
>> multiple msgs work. I think that call to Transfer is a small thing...
>
> I disagree and the primary reason why I think so is that it doesn't work
> with the multi interface to do it this way. And since it needs to be
> done differently to make it work with the multi interface, we can just
> as well aim to make it done the same way for both to keep things simple
> (well, as simple as we can anyway).

Well, another way might be to transition back and forth between the SETUP
and TRANSFER states until all messages have been read.

>> If we explicitly do not support more than a single message, then I
>> think we can use the transfer logic as you wish it used. It would make
>> it less efficient to download lots of messages with CURL, but maybe
>> that's not a big deal.
>
> Maybe we can allow the ";uid=1:3" style of transfer just get everything
> in one transfer and let the app figure out how to make anything out from
> it? It would match how we currently support multiple ranges with HTTP:
> it will provide a data stream that the app needs to parse.

Yeah, but I don't know how any app that is at all generic could really
know the boundaries..especially since headers are not included in the
data stream (you have to get headers with a separate IMAP request).

We could inject something like ### HACK: CURL_START_OF_MSG___###\r\n
into the datastream or something like that to let them parse it if
we don't want to deal with callbacks, but that seems a bit lame even
to me :)

If we allow uid=1:3 in any manner, we are going to have to be able to
handle arbitrary Transfer logic between arbitrary header logic because
imap intersperses headers between each message, even when you get them with
a single URL such as uid=1:3.

>> When I started hacking on imap the pp->cache contained headers + data.
>> I don't see any way to avoid this while still using pingpong logic.
>
> The pingpong logic is only a set of helper functions. There's nothing
> that forces the IMAP code to use that if it ends up better and nicer
> using other means. Or possibly we can improve the pingpong functions to
> work better for IMAP. After all, the pingpong functions very recent
> (simple moved from the previos FTP code and converted to become more
> generic) and we haven't yet really ironed out all the wrinkles from them
> yet.

I find the pingpong code quite difficult to read & understand. I have
a solution that is good enough for my needs (I don't actually need the
ability to get multiple messages..just seemed a neat thing to support),
so I'll probably try to get what I have acceptable for commit and then
let it rest for a while.

> Let me also just say it again that I seriously appreciate your hard work
> on this and I'm glad you're doing it!

No problem..I've used curl happily for years..never hardly had to read the
code at all and it just worked. Sorry I had to peel back the curtain
and see the warts ;)

Seriously..it's allowing me to add 5-6 interesting protocols to our
traffic generator with a few weeks' effort..not a bad deal at all!

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