[bind10-dev] proposal: separate ModuleCCSession and ConfigData

[JINMEI Tatuya / 神明達哉]

At Wed, 4 Apr 2012 09:11:10 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > > If we would have the ConfigData class, I think the
> > > ModuleCCSession should inherit from it, because handling own config data should
> > > contain all the things as handling any config data (merging the configurations,
> > > etc). It would just need some more code for validation, etc.
> > 
> > Hmm, I'm afraid I don't follow this logic.  BTW, there is indeed a
> > ConfigData class right now, and ModuleCCSession inherits from it.  I
> > actually thought that relationship was one reason why ModuleCCSession
> > had now so many responsibilities and was much complicated, and I
> > proposed to stop doing the inheritance for clearer separation of
> > responsibilities.
> 
> OK, I'll try to simplify it a little bit.
> 
> Both the ModuleCCSession and the ConfigData classes handle some
> config, right? The ModuleCCSession is for the config of the current
> module and the ConfigData for some foreign one. But this shares a
> lot of functionality. I don't care much what exact technique is used
> to share the code, but I think stuff like merging a config update
> and calling an update hook is something to be written just once.  So
> maybe (with better naming):
> 
>                 ConfigPart (or ConfigModule, or ConfigData)
>                 /                          \
>                /                            \
>             LocalConfig                    RemoteConfig
>             (Does stuff like
>             validating the config)
>            /
>           /
>       ModuleCCSession
>       (Adds command hooks)
> 
> 
> Anyway, your proposal looked like there'd be no relation between the two, but
> they both would contain a bit of common code, which would then be duplicated.

I'm afraid I'm still confused, but in any case in my proposal the new
ModuleCCSession is almost free from configuration.  It's only
responsible for communication with cfgmgr (handling data as opaque
data) and maintaining subscriptions.  The new ConfigData is solely
responsible for managing configurations.  So, actually, the proposal
is more for avoiding duplicate code.  I don't understand why it gave
you the opposite impression - maybe the initial explanation was so
rough.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.