BIND 10 #1595: Make the share name configurable

[BIND 10 Development]

#1595: Make the share name configurable
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120207
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  3
Feature Depending on Ticket:         |           Total Hours:  0
  Socket creator, multiple auths     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

 > > '''general'''
 > >
 > > In general, I'd like to avoid hardcode specific values like "auth" or
 > > "resolver" in .cc's.
 >
 > Hmm, what would be the better place to put them? I don't think it makes
 sense to put them into the configuration, because we don't support
 different configurations for different auth servers, etc, so I wouldn't
 like to clutter the configuration for user, as it would have no effect for
 him. And the initLogger hardcodes the name as well.
 >
 > Maybe there could be a single name in a constant at the top and use it
 in initLogger and initRequestor?

 Honestly speaking I didn't have a specific suggestion, but defining a
 constant (C-)string (maybe in a header file?) and using it sounds
 reasonable.

 > > - is it okay to pass an empty string for app_name to
 > >   initSocketRequestor() (then to SocketRequestorCCSession)?
 > > - is it okay to pass non empty share_name to requestSocket() when
 > >   share_mode is not SHARE_SAME?  Also, while it may be inferable, it's
 > >   not clear from the documentation how exactly share_name works with
 > >   SHARE_SAME.
 >
 > I tried to describe it little bit more in the description.

 This is slightly different what I envisioned for "how exactly...".
 What I wanted to see is something like this:

 - if mode is DONT_SHARE, requestSocket() will succeed iff no one else
   has opened an FD for the requested protocol, address and port.
 - if mode SHARE_SAME, ...(share_name will appear here...)
 - ...

 > > '''socket_requestor_test.cc'''
 > >
 > > - not new to this case, but I don't see why we need to use ASSERT_xxx
 > >   instead of EXPECT_xxx in the added tests.
 >
 > I'm not sure, but it looks like if there would be 0 messages in the
 session, the next one would segfault. I guess Jelte put ASSERT_ everywhere
 for consistency and I just copy-pasted it. Should I try to change some of
 the ones where it doesn't seem necessary?

 I'd leave it to you.  While EXPECT_ should be generally preferred over
 ASSERT_ whenever the former can be used safely, it wouldn't matter
 much in practice because existing tests are generally expected to pass
 anyway.  On the other hand, since this task is relatively small, maybe
 piggyback'ing such cleanups makes sense.

 > > - related to whether it's okay to pass an empty app_name to
 > >   initSocketRequestor(), test using "" seems to be less reliable.
 > >   Since "" could be used as a default as well, I cannot be so sure if
 > >   name is the default or the string auth_srv_unittest passed (both are
 > >   "") here:
 > > {{{#!c++
 > >         EXPECT_EQ(expected_app_, name);
 > > }}}

 This part looks okay.

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