On Sat, 15 Jun 2013, NSRT Mail account. wrote:
Please remember that we don't top-post on this list.
This patch looks pretty good to me.
Regarding design mistakes, is there a good reason to also need to specify
not to disable progress? (noprogress = 0) Why not imply it when specifying a
callback?
I agree, but I'd then prefer to make it less similar to the old callback as
right now it is such a drop-in replacement that it would feel a bit wrong to
alter such a little thing as well with the new callback.
Regarding unknown values, since we're switching to off_t, and off_t is
signed, there is no sane meaning to its negative values. We just transfered
-4225 bytes? Perhaps <0 can signify unknown, and 0 only means 0.
That's one way, sure. A little downside of using negative numbers is perhaps
for those who don't care and just want to do like today and show 0 until it
gets known...
Another way could be to pass on the information to the callback as a pointer
to a struct with a "known" bitfield:
struct curl_xferinfo {
curl_off_t dltotal;
curl_off_t dlnow;
curl_off_t ultotal;
curl_off_t ulnow;
unsigned int knowndata;
#define DLSIZE_KNOWN (1<<0)
#define ULSIZE_KNOWN (1<<1)
}
And pass 0 while unknown like today, but also set the bitmask to tell wether
the field is truly 0 or rather unknown.
Something that struck me, is if we should take the opportunity to perhaps also
include "state" in such a struct? Oh and I just spotted than Dan F brought
pretty much the same idea, but yeah it might be even better to offer that in a
new getinfo-option...
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
