[Ns-developers] Bug 215 (Name List)

[craigdo@ee.washington.edu]

> >   Names::Name ("/Names/client", "eth0", d.Get (0));
> >   Names::Name ("/Names/server", "eth0", d.Get (1));
> 
> The name of the method 'Name' on class 'Names' strikes me as utterly
> confusing. How about simply 'Set' or 'Add' (I prefer the latter):
> 
> Names::Add ("/Names/client", "eth0", d.Get (0));

That's fair.  I've called it several things over the past couple of days.
I've been spending all of my time recently naming objects (using Names
namespace methods to Name objects -- not adding objects to anything), so I
began to think of it that way; but I can work with Add if that's the
consensus.  I may be the wrong person to decide on names, after all, since
I've been down in the guts of the system where it is obvious what is going
on.  It didn't occur to me that the word Name can be used as a verb, an
adjective or a noun :-)

Anyway, I'm fine with Add.

> I think that it would also be nice to have the simpler 
> non-hierarchical
> version which is the version I thought we had originally discussed on
> the list:
> 
> Names::Add ("ap", d.Get (0));

This does exist, and will add a name to the root name space.  I just didn't
list out all of the possible variations since some folks don't like long
detailed emails. ;-)  The reason I prefer the version I showed is that it
encourages people to remember that these strings aren't arbitrary in exactly
the same way that Config paths aren't arbitrary.  Each intermediate segment
in a "/Names" name space path has got to refer to a previously named object
(like each segment in a config name space path has got to refer to an
existing Atribute or type id).  I suspect the version you show above will be
most commonly used, though, since it's easiest to type.  

There are currently three variations you can use:

The most basic API Adds a name/object association to the name space "under"
a previously named object context:

  Names::Add (Ptr<Object> context, std::string name, Ptr<object> object)  

There is also a version that translates a string context into an object and
calls the previous method  (This is the one I showed in my email):

  Names::Add (std::string context, std::string name, Ptr<object> object)

And there is also a version that takes one string.

  Names::Add (std::string name, Ptr<object> object)

This is equivalent to using the first method but passing a zero Object
pointer as a context, or using the second method with context set to
"/Names".  To extend your example a little:

  Names::Add ("ap/eth0", d.Get (0));

I'm planning on also allowing someone to do this:

  Names::Add ("/Names/ap/eth0", d.Get (0));

just for convenience, both of which would produce exactly the same result --
being translated into

  Names::Add ("/Names/ap", eth0", d.Get (0));

I think it's pretty flexible.  I believe that the hardest part will be
communicating that the string isn't just a collection of arbitrary
characters.  This also seems to be the challenge of Config::Connect.  But, I
think if you understand one, you understand the other, especially if we
document the conceptual models similarly.

> > You can look up named objects, of course.  Here I install 
> the server app on
> > the node defined by its name and ditto for the client.
> > 
> >   ApplicationContainer apps = server.Install (Names::Find<Node>
> > ("/Names/server"));
> >   apps = client.Install (Names::Find<Node> ("/Names/client"));
> 
> I would much rather prefer to see:
>   apps = client.Install ("/Names/client");
> 
> which means a couple of extra overloads in ApplicationContainer but,
> well, it seems like a small price to pay for the convenience.

Yes, there is still further work to be done.  This is one of the things
we've talked about.  Another is changing the trace file names if the devices
are named.
 
> (note that this does not mean that there should not be a 
> Find<> method,
> it just means that it would be nice to not have to use it in 
> this case)

Yes, there's got to be a Find method to be used down in Resolver::DoResolve.

Anyway, I wanted to touch base with everyone before I went much further.
Since there don't seem to be any major problems, I'll start cleaning this
up, documenting it further, etc., and shoot for trying to be ready for merge
in the next couple of days.  I'll put together a patch and send it to Raj;
and I expect he'll call for a "real" design review.

Regards,

-- Craig