Created an attachment (id=153) [details]
Names patch

Some options here to consider:

1) whether to just overload GetNode(std::string name) instead of a separately
named method GetNodeByName()

2) whether to add additional methods to return a node index or net device index
(rather than Ptr) by name

+  if (found > 1)
+    {
+      NS_ASSERT_MSG (false, "More than one node with name: " << name);
+    }

Should probably be:
      NS_ASSERT_MSG (found <= 1, "More than one node with name: " << name);

Idem for device name.

Additionally it would be nice if Node::GetName would return "node%i" with the
node number, in case no node name has been set.

(In reply to comment #3)

> 
> Additionally it would be nice if Node::GetName would return "node%i" with the
> node number, in case no node name has been set.
> 

Good idea.  

I bumped to P3 since we are still noodling on it-- proposed to check in after
ns-3.1.

(In reply to comment #4)
> I bumped to P3 since we are still noodling on it-- proposed to check in after
> ns-3.1.

Sure.  Personally I had in mind using node name for "log context", but since
the log context stuff was not fully implemented (and probably never will), this
kind lost some of the appeal to me.

I am not volunteering to do any work, but it would nice to finish this for NS
3.3.

Mathieu suggested the following to me a little while ago:

class NameContainer
{
public:
  void Set (Ptr<Object> obj, std::string name);
  template <typename T>
  Ptr<T> Get (std::string name);
};

This allows any Object to have a unique name in the system, and doesn't cause
all nodes to carry a std::string.  Thoughts?

by the way, I also would like to resolve this for ns-3.3.

(In reply to comment #7)
> Mathieu suggested the following to me a little while ago:
> 
> class NameContainer
> {
> public:
>   void Set (Ptr<Object> obj, std::string name);
>   template <typename T>
>   Ptr<T> Get (std::string name);
> };
> 
> This allows any Object to have a unique name in the system, and doesn't cause
> all nodes to carry a std::string.  Thoughts?

I don't like that:
  1. We have would Node::GetId () but no Node::GetName ();
  2. Everything gets put into the same namespace, nodes or whatever;
  3. There should be trace path support for node names, otherwise what's the
point.

An intermediate possibility would be to put the names in the NodeList class. 
That would make a lot of sense, conceptually, and avoid the need for each node
to carry a name.

(In reply to comment #8)
> (In reply to comment #7)
> > Mathieu suggested the following to me a little while ago:
> > 
> > class NameContainer
> > {
> > public:
> >   void Set (Ptr<Object> obj, std::string name);
> >   template <typename T>
> >   Ptr<T> Get (std::string name);
> > };
> > 
> > This allows any Object to have a unique name in the system, and doesn't cause
> > all nodes to carry a std::string.  Thoughts?
> 
> I don't like that:
>   1. We have would Node::GetId () but no Node::GetName ();

The main requirement is that we are trying to give a name to other objects than
nodes.

>   2. Everything gets put into the same namespace, nodes or whatever;

Yes, the use-case we are trying to support here is that of a global namespace
for objects.

>   3. There should be trace path support for node names, otherwise what's the
> point.

Good idea: /Names/xxx/...

> An intermediate possibility would be to put the names in the NodeList class. 
> That would make a lot of sense, conceptually, and avoid the need for each node
> to carry a name.

That does not seem very desirable because other objects than nodes want names.

I am fine with NameContainer patch provided that it is available at the
src/core level, and that we keep the existing std::string names in the
NetDevice.  In particular, implement also:
Ptr<NetDevice> Node::GetDeviceByName (std::string name);

I feel that NetDevice are a special case because it would be nice to be able to
reuse common strings for these across nodes, such as "eth0".

And I am fine with removing names from Channel and making those objects use the
name container.

Created an attachment (id=317) [details]
Simple bimap for name/object association plus use in csma-one-subnet.cc

Here's a quick and dirty NameList to address bug 215.  Even as simple as it is,
it makes some code much more readable.  It is not completely integrated,
though,

For example, there are new device helper methods that look like

  CsmaHelper::EnablePcap (std::string filename, std::string devname)

and you use them like

  CsmaHelper::EnablePcap ("csma-one-subnet", "Node0/eth0");

the problem is that the pcap trace file still has a file name that looks like,

  csma-one-subnet-0-0.pcap

which kindof defeats the high level purpose of naming.  We should really create
files that reflect the names given in the script,

  csma-one-subnet-Node0-eth0 

I'm sure there's much more that needs to be done, but this patch provides basic
naming.

Craig is going to investigate the following:

1) indirect the proposed Node::GetDeviceByName (std::string name) through the
NameList, allowing for non-unique names such as "eth0", and remove the private
std::string in class NetDevice (also remove the channel name).

2) try to prototype whether these names could also be used in the config
subsystem

There are additionally some API issues regarding how we expose this at the
helper API level, beyond whether the names exist also in the config namespace. 
For instance, one can conceive of a CsmaHelper that, by default or by explicit
configuration, adds an "eth" or "csm" prefix name to all devices when created,
and does the right thing to assign "eth0" "eth1" (or "csm0" "csm1") in order,
so that later, a user would have the expectation that if there is one CSMA
device on the node, it must be "csm0"

Created an attachment (id=356) [details]
Proposed object name service

This is a proposed addition for ns-3.4 -- an object name service.

(From update of attachment 356 [details])
Proposed bits now in repo craigdo/ns-3-names