BIND 10 #2573: extend MasterLoader and ZoneLoader to return additional states including # of loaded RRs

[BIND 10 Development]

#2573: extend MasterLoader and ZoneLoader to return additional states including #
of loaded RRs
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130122
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  1.81          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei
 * totalhours:  0 => 1.81


Comment:

 Hello

 Replying to [comment:6 jinmei]:
 > Actually, I wondered the same thing, so I made that change.
 > getPosition and getSize were now deprecated and removed from
 > `ZoneLoader`.  I chose to return an integer between 0 and 100 instead
 > of floating points as integers are generally easier to use and I didn't
 > see the need for higher granularity than that.  But that's not a
 > strong opinion.

 The int is probably OK, I just wonder about two things (but feel free to
 ignore them):
  * Sometimes, 100 is too little granularity. Some programs write
 percentages with precision of tenths (so 42.1%, for example). Also, if
 someone created a GUI progress bar, these are usually longer than 100px
 (with screens in sizes of 1000+). If the progressbar had a length of 1000,
 then it would jump by blocks of 10, which is visually disruptive in case
 it loads for longer time (5 minutes, for example). Maybe keep it as int,
 but set the maximum to 10000, or something? It would be no problem to
 divide it by 100 when writing full percents.
  * If the `PROGRESS_UNKNOWN` was something large instead, we could use
 `unsigned`. Wouldn't it be better?

 > I made one additional cleanup at the last commit (see the log), which
 > may be debatable.  If so, I'm okay with skipping that part for this
 > task.

 That one looks good.

 I also noticed some very minor whitespace and capitalization problems, and
 it seemed easier to just fix them on the branch. I don't think you would
 disagree with them, but if so, that's OK, feel free to revert.

 So I think it is OK to merge (with or without the change to range).

 I also noticed something that made me think little bit, so I'd like to ask
 if there's a rationale behind it. You seem to place the bound paramethers
 of method last, eg:

 {{{#!c++
      boost::bind(addRR, _1, _2, _3, _4, _5, updater_.get(), &rr_count_)
 }}}

 Is that some habit common with C++? From haskell, I'm used to placing the
 bound ones first (since it's then more convenient, since if they're first,
 there's no need to use the lambda notation):

 {{{#!haskell
     -- When bound are first
     addRR updater_ rr_count_ -- Which binds first 2 parameters and creates
 a function taking 5
     -- vs.
     \_1 _2 _3 _4 _5 -> addRR _1 _2 _3 _4 _5 updater_ rr_count_
 }}}

 Obviously, this motivation is not present in C++ (since both require
 `boost::bind` with listing all parameters), so I wanted to ask if there's
 any for the opposite or if it just doesn't matter.

 Thanks

-- 
Ticket URL: <http://bind10.isc.org/ticket/2573#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development