[Ns-developers] ns-3-names comments

[craigdo@ee.washington.edu]

> > In the Config (trace) code
> >
> >  /NodeList/0/DeviceList/1/  Rx
> >  ^^^^^^^^^^^^^^^^^^^^^^^^   ^^
> >  This is the context        This is the attribute
> 
> 
> Actually you are mistaken.  The context that you receive in the trace
> callback (Config::Connect) is the whole path, 
> "/NodeList/0/DeviceList/1/
> Rx".

The difference you point out is, like so many things, based on where you are
looking.

In the search methods of the config code, you create things called contexts
that really do not include the attribute name.  However, when the
object->TraceConnect method is called from the config code, a string called
"ctx" (context) is created that consists of the internal config code context
plus the attribute name.  What happens in a trace connect is explicitly

  std::string ctx = m_contexts[i] + name;
  object->TraceConnect (name, ctx, cb);

So, yes, from a trace user perspective the context seen in the callback
includes the attribute name

  /NodeList/0/DeviceList/1/Rx  Rx
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^
  This is the context          This is the name

But when you are in the config code, searching the config path, you are
building m_contexts which do not include the name.  If you are down in the
config code, the contexts there mean the same thing as in the names code,
which is one reason why the naming code slides in so nicely.  It is true
that

  /NodeList/0/DeviceList/1/  Rx
  ^^^^^^^^^^^^^^^^^^^^^^^^   ^^
  This is the context        This is the attribute name

This can all be pretty confusing unless you really have your bearings (why
emails sometimes get so long :-) and know what terms are overloaded where.
I tried to make distinctions that I thought helped based on where I thought
the most common use cases would put most users; and then used terms
reflecting that point of view.

I hope that if one uses the name service in a script in the ways expected,
the calls make sense from that point of view.  I hope that if one uses the
name service down in the config code, the calls there make sense from that
point of view.  I hope that even if one uses the lower level names code
outside of these specific places, the API is understandable enough to make
sense.

I thought it ended up working out well.  Let me ponder your suggestions for
a short while and I'll get back to you ...

Regards,

-- Craig