On Tue, 6 Apr 2010, Ben Greear wrote:
If the above URL can be supported without the source becoming a maze, then
I'm all for it.
That URL example is straight out of the RFC for IMAP URLs. This will
currently be a pain for users to interact with since we need some way to
tell the users where one message stops and another starts. We'd probably
need new start-msg/stop-msg callbacks or something like that.
Exactly, and that is partly what the FTP wildcard patch introduces!
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).
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.
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.
Let me also just say it again that I seriously appreciate your hard work on
this and I'm glad you're doing it!
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
