[Ns-developers] Bug 215 Name Container

[craigdo@ee.washington.edu]

> >  NameList::Add (devices.Get (3), "Node 3/eth0");
> 
> Here I think the arguments should be swapped.  Normally we are used to
> assignment where the identifier comes before the value.  It 
> is that way in
> Assembly, C, and Python (PyObject_SetAttrString(object, 
> "string", value)).
> I'm sure there are more examples of prior art that I could find... :-)

Well, I think in Python you would probably do something like

  copy (source, destination)

but in C and assembler you would probably see

  copy (destination, source)  or
  assign (identifier, value)

That is exactly what I did in this case.  Not that it really matters, but
it's the most common way I've seen it done.  I've seen it done both ways.
If there is a strong call for it to be different I'm find with changing it.
But, here's the simple prior "art" that corresponds to what I chose:

  strcpy (destination, source);
  NameList::Add (device, name);

> Do we really want to allow slashes in the names?  I could 
> imagine a future
> extension of that class to support tracing, e.g. Config::Connect
> ("/NameList/AccessPoint/DeviceList/0/Rx", ...).  Slashes would kind of
> interfere with this scheme.

Right now the name string is just an unchecked string.  It's not checked
since I'm not sure yet what to check for.  This is a big part of the reason
I'm uncomfortable with pushing the patch at this late date.  Allowing any
character in names could also cause file name confusion, for example. 

> > To be honest, I'm not sure that this is well-enough thought 
> through to go
> > in
> > this release.  One example of an inconsistency is the trace 
> file names.
> > They will still come out like "csma-one-subnet-0-0.pcap" 
> when I think they
> > really should come out "csma-one-subnet-Node 0-eth0.pcap" 
> or something
> > similar.
> >
> > Also, there isn't good integration with attributes/tracing 
> at a low level.
> > For example, it would be nice to be able to refer to an 
> attribute using the
> > name list translation
> >
> >  "Node 0/eth0/EncapsulationMode"
> >
> > But this isn't implemented nor really thought through.
>
> Indeed, it is not thought through.  I can see already that the
> Config::Connect parser will be confused by the "Node 0/eth0" name...

The changes to the config code will need to go far deeper than just
arranging the names to look similar.

> > What are your thoughts about pushing this into ns-3.3?
> 
> It might be better to skip ns-3.3 to avoid possibly breaking 
> the API in the
> future.

That is my concern.

> One other idea occurred to me is to support object groups.
> 
>    NameList.:Add (std::string name, NodeContainer container);
>    NameList.:Add (std::string name, DeviceContainer container);
> 
> For instance, you may want to connect to only the core 
> routers, not edge
> routers, in a hypothetical scenario:
> 
> Config::Connect ("/NameList/CoreRouters/*/....", ...)
> 
> The same thing with NodeList is difficult to do.  You have to 
> do (IIRC):
> 
> Config::Connect ("/NodeList/[11-33]/...", ...)
> 
> where 11 and 33 and the start and end indexes of the nodes in 
> that group.
> 
> To make this work you'd need some code that converts non-Ptr-based
> NodeContainer to a Ptr-enabled ObjectContainer or something 
> like that.  Idem
> for the other containers.

I had thoughts along similar lines and added support in the helper layer for
NameContainers.

In any case, my take is that the name container needs to be expanded from a
bug fix into a fairly extensive new feature that will be added into a future
release.

-- Craig