BIND 10 #1513: communication to b10-xfrout from b10-ddns

[BIND 10 Development]

#1513: communication to b10-xfrout from b10-ddns
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120612
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  4
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 jelte]:

 Thanks for the review.

 > Completely unrelated, but the test class TestDDNSession misses an S in
 its name there :)

 Ah, right, fixed.

 > But more seriously, one of the docstrings already says that we should
 really have async operations here. We actually do have them now, afaik,
 'just' not in python, so maybe we should add that soonish.

 Ah, okay, it's #1914.  I'm not sure if (an imaginary python version
 of) this behavior covers all issues in this context (simply because
 I've not looked into it), but in any case the python version should
 have better asynchrony.

 > But barring those, I wonder if b10-ddns and b10-xfrin shouldn't simply
 make this a notification instead of a request-response, i.e. just send out
 'hey xfrout, in case you're listening, send updates for this zone', and do
 not expect anything back from xfrout.
 >
 > That would cause us not to be able to report errors here, but on the
 other hand, our modules aren't waiting for 4 seconds for a response
 message that never comes if the admin does not run xfrout (which may or
 may not be a common scenario, but i do not run xfrout on my bind 10
 instance right now).
 >
 > Unfortunately we also have no unhackish ways to figure out what is
 running, which we could of course also add, but in that case it's probably
 better to focus on async messaging.

 Hmm, making the notification to xfrout one-way may make sense because
 the (DNS) notify itself is an unreliable optimization.  But I suspect
 we need to be more sensitive about any errors for the notification to
 auth, and if we do it for some, omitting it for the other may not buy
 much (at least in terms of the amount of code ddns needs to have).

 I'd also note that the send operation can also block, so even if the
 notification is one-way, we'll still have to worry about
 blocking/asynchrony issue.

 > Barring the above, the code looks good.

 So, can I interpret it as this branch can now be merged?

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