BIND 10 #1986: b10-auth shouldn't try to forward update requests without ddns running

[BIND 10 Development]

#1986: b10-auth shouldn't try to forward update requests without ddns running
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:  Next-Sprint-
  defect                             |  Proposed
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  b10-auth                           |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:  DDNS   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Replying to [comment:4 jinmei]:
 > Replying to [comment:3 vorner]:
 > > The point 2. would really use the support of notifications, to be
 implemented properly. Should we consider doing them?
 >
 > Do you mean one of the msgq tasks by notifications?

 Yes, thats the exact thing I mean.

 > I simply don't know if it should be considered part of it, mainly due
 > to my poorer understanding of the whole things.  But if a general
 > framework can solve this particular issue cleanly, that will be
 > certainly a longer term move.

 Yes, the auth would register for notification „DDNS ready“ and then act
 accordingly when it comes (it would ask over some call for the path of the
 socket, both on startup, which could fail if auth started sooner, and when
 the notification comes). Then it would register the disconnection
 notification, so it would know when DDNS stops.

 > In any case I personally think the goal of this ticket should be
 > achieved by the next release, so we should choose a reasonably
 > lightweight approach, considering the tradeoff between having another
 > quick hack and cleaner but timeconsuming solution.

 If it is so, I'd prefer having a real ugly hack that would force us doing
 it properly sometime. We have a huge army of reasonable compromises that
 just live there forever because there's no real driving to do it properly.

 But I don't know how time consuming would be make the notifications work.
 For this one to work, we probably only need like two small wrapper
 functions, one to send the notification with some corresponding address
 and one to register the callback for it in C++. In long term, we would
 need registration of the callback on python too, which would be tricky,
 and having the list of notifications in the spec file, but I think this
 could wait.

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