BIND 10 #2930: Sending notifications over msgq

[BIND 10 Development]

#2930: Sending notifications over msgq
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  Inter-module  |  reviewing
  communication                      |                    Milestone:
            Keywords:                |  Sprint-20130528
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  3             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:7 jinmei]:
 > - not sure if it's related, but cmdctl unittest fails for this branch:
 > {{{
 > Running test: cmdctl_test.py
 > ....................................E
 > ======================================================================
 > ERROR: test_wrap_sock_in_ssl_context (__main__.TestSecureHTTPServer)
 > ----------------------------------------------------------------------
 > Traceback (most recent call last):
 >   File
 "/Users/jinmei/src/isc/git/bind10-2930/src/bin/cmdctl/tests/cmdctl_test.py",
 line 741, in test_wrap_sock_in_ssl_context
 >     BUILD_FILE_PATH + 'cmdctl-certfile.pem')
 >   File "/Users/jinmei/src/isc/git/bind10-2930/src/bin/cmdctl/cmdctl.py",
 line 610, in _wrap_socket_in_ssl_context
 >     raise socket.error
 > socket.error
 > }}}

 I don't see any possible way how it could be related. Also, it doesn't
 fail for me. Is it repeatable? Master passes (or, the base of the branch)?

 > - I'm assuming 9d7bd1274b7ff4578e108c8c13bad81cc2867d14 of master is
 >   part of this branch and should be reviewed.  Is there other such
 >   commit?

 Sorry, I forgot to mention that one, I pushed it by accident. This is the
 only one.

 > - are we going to describe the concept of notification in API docs?
 >   or is there already such description?

 Which API doc's do you mean? It is described in the cc-high.txt (I updated
 little detail there now). Do you mean some other?

 > - is there a restriction of the type of params?  can it be, e.g., an
 >   integer?

 I believe the commands don't restrict the type of parameters either, so I
 didn't impose any restriction. But I noted that the common way is to pass
 a map/dict there.

 > - any exceptions?

 No, except from what the underlying sending of message might throw.

 > - on a related note of the concept description, I'd like to describe
 >   what kind of message will be sent, even if the user doesn't have to
 >   know about it.

 I added a reference to the cc-high documentation. I don't like duplicating
 it across many places and I don't want to clutter the documentation with
 internal serialization of information.

 > - maybe missing exception cases

 I don't think I can reasonably trigger the ModuleCCSessionError. But even
 if I could, it wouldn't be testing anything in the method anyway.

 > - what if we pass bogus types of parameters, like an integer for the
 >   group?

 Then I believe python will throw somewhere. But I don't want to add
 explicit check for the types, because:
  * It's not the python way. Python uses duck typing, so anything that
 behaves correctly is the correct type.
  * We don't do it in any other functions (we do so in the C++ bindings,
 but that's because we need to convert it to C++ types, which are fixed).
  * If we checked such things at every place, the code would get completely
 unreadable.
  * It's not expected error to happen. If something else is passed, it's
 programmer error and the traceback that'll get out should be good enough
 and explaining so the programmer will know what to fix. It's not something
 that should ever be caught, so we don't need to specify specific type of
 exception either.

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