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