Re: [netmod] Augmenting an unimplemented module

[Martin Bjorklund <[e-mail]>]

Lou Berger <[e-mail]> wrote:
> 
> 
> On 2/8/2017 3:34 PM, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[e-mail]> wrote:
> >> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
> >>> Lou Berger <[e-mail]> writes:
> >>>
> >>>> On February 8, 2017 10:16:14 AM Juergen Schoenwaelder
> >>>> <[e-mail]> wrote:
> >>>> ...
> >>>>> We should perhaps start a separate thread but I fail to see why tags
> >>>>> require new editing primitives.
> >>>> It was an intentional design choice/preference by one of the authors.
> >>>> Basically, Chris thought it was easier from a client perspective.  He's the
> >>>> user, so he won:-)
> >>> The tags in the library and the tags in a module are updated at the same
> >>> time and represent logically the same list of tags. Its clear this
> >>> happens with an RPC. It seems a lot less clear this would (or should)
> >>> happen if one edited only once location.
> >>>
> >> I am not convinced by the design. We have lots of other resources
> >> where we have configured and system determined values. I do not see
> >> that tags are any different.
> > I agree.  *If* you want a config true datastructure, it should be
> > modified with the normal edit operations, not special RPCs.  There are
> > several reasons for this.  For example, how would your new RPCs interact
> > with locks?  With candidate?  With startup?
> I defer to Chris on us of RPCs in general, but an interesting use case
> that is supported with RPCs is tag modification in RO modules.

Yes, but we are talking about configuration data.

> > Also I am not sure it is a good idea to add configuration meta-data
> > that really should be common across all modules into the modules
> > themselves.  Another approach is to keep a separate list with the
> > tags, indexed by modulename and revision.
> >
> This is what the library augmentation is aimed at.

Yes that is needed, but if you also want to let clients configure
tags, you need another list.


/martin