BIND 10 #172: cc channel - use JSON

[BIND 10 Development]

#172: cc channel - use JSON
----------------------+-----------------------------------------------------
 Reporter:  larissas  |        Owner:  stephen                                       
     Type:  task      |       Status:  reviewing                                     
 Priority:  major     |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  msgq      |   Resolution:                                                
 Keywords:            |    Sensitive:  0                                             
----------------------+-----------------------------------------------------
Changes (by jelte):

  * owner:  jelte => stephen


Comment:

 Replying to [comment:11 stephen]:
 > >> __src/lib/cc/data.h__
 > >> Remark: The choice of constants for the "types" enum: the names
 "string", "list"
 > >> and "map" - although aptly named - could be confused with type
 declarations.
 > >> Leave for now, but perhaps change in the future?
 > >
 > > If you have suggestions, i'd gladly hear them, I also had the plan of
 renaming
 > > the namespace (data), which has a related problem, so we can nicely
 fit that into
 > > one ticket :)
 >
 > How about STRING, LIST and MAP? (Together with INTEGER, DOUBLE, NONE
 etc.)
 >

 Let's do that in another task :)

 >
 > >> __src/lib/cc/data.cc__
 > >> count_chars_i()
 > >> from_stringstream_number()
 > >> :
 > > doh, fixed (keep dividing until < 1, i'm thinking there's a more
 efficient way for this :)
 >
 > In the code for reading characters from the string, how about reading
 the next string token from the stream then using boost::lexical_cast to
 convert it to a number?  That way you can attempt to cast it to an int
 and, if it throws a bad_lexical_cast exception, try casting it to a
 double.
 >

 hmz, relying on exceptions for expected behaviour raises all hairs in my
 neck. But this code isn't efficient either. Perhaps this is a good example
 for a micro benchmark.

 >
 > __src/lib/cc/data_unittests.cc__
 > Question about the code being tested: I note that if an object
 containing (say) the name/value pair '"a" : 1' is merged into an object
 containing the pair '"a" : 2', the result is an object containing the pair
 '"a" : 2', i.e. the result is the value from the target.  But if it is
 merged into an object containing '"a" : null', the result does not contain
 "a" at all.  Is this the desired behaviour? (i.e. why does the result not
 contain '"a" : null'?)
 >

 We need a way to remove elements from maps, through hints in the structure
 itself, setting something to null seemed like a good compromise. I'll
 update the merge documentation to be clearer about this.

 >
 > __src/lib/config/module_spec.cc__
 > >> General: this file contains a "getType_string()" function that
 returns a string
 > >> representation of the Element::types enum, and a getTypes_value()
 function that
 > >> does the inverse. These functions would be better made static methods
 of the the
 > >> Element class. (They have got out of sync with the class; there is no
 translation
 > >> for the "null" type.)
 > >
 > > ok done, renamed them to nameToType and typeToName though
 >
 > module_spec.cc still needs to be updated to call them.

 doh. r2322

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