[Ns-developers] ns-3.4 action plan

[Tom Henderson]

>-----Original Message-----
>From: Gustavo Carneiro [mailto:gjcarneiro at gmail.com]
>Sent: Tuesday, February 3, 2009 09:09 AM
>To: 'Tom Henderson'
>Cc: 'Raj Bhattacharjea', 'ns-developers'
>Subject: Re: [Ns-developers] ns-3.4 action plan
>
>2009/2/3 Tom Henderson <tomh at tomh.org>
>
>> Raj Bhattacharjea wrote:
>>
>>
>>> ----Object Naming System----
>>> The names discussion has wound down, and Craig's repository is
>>> undergoing testing for merge within a few days.
>>>
>>
>> There have been two changes to the above repository recently, based on some
>> discussion I had with Craig.  The first is to allow the "/Names/" prefix to
>> be omitted in most places, to improve readability.
>>
>> i.e. this used to be the required syntax:
>>  Names::Add ("/Names/server", n.Get (1));
>>
>> but this is also equivalent now:
>>  Names::Add ("server", n.Get (1));
>>
>> The only place you cannot use this shortcut is in the Config commands,
>> because that system always expects a fully qualified path name:
>>
>>  Config::Set ("/Names/server/eth0/Mtu", UintegerValue (1234));
>>
>>
>> The second change is to allow objects to be renamed:
>>
>>  Names::Rename ("node0", "access-point");
>>
>> Rename() will facilitate future auto-naming of objects.  In particular, if
>> helper classes are configured to name objects automatically (as I've
>> suggested before), there may be a desire to replace an auto-generated name
>> with a more meaningful name.
>>
>> I think that the above is ready for merge.  I think it would be nice if we
>> could configure the helpers to optionally add names to certain objects
>> (particularly devices), such as a convention that all Csma NetDevices
>> automatically end up with names like "eth0", "eth1". Attached is the start
>> of a patch along these lines.  I think that the auto-naming can be built on
>> top of what Craig already has, in the helper classes, so I do not want to
>> suggest holding the merge of what is already there to work on autonaming-- I
>> am just bringing it up as food for thought.
>
>
>But... NetDevices already have names, and for instance CsmaNetDevice names
>are already eth0, eth1, ... by default (thanks to me).  If we get two
>netdevice names, one in "Names" and one in the netdevice itself, it will be
>confusing (as much as separate L3/L2 netdefive indexes are confusing now).
>I prefer to keep the existing API of NetDevice::GetName (), for the sake of
>convenience and API stability, but I am ok if NetDevice::GetName () is
>implemented to fetch the name from the Names list, just as long as we stick
>to the Don't Repeat Yourself principle.
>

Yes, we had discussed previously that NetDevice::GetName implementation could be indirected through the name system.  That would be fine with me.  However, to do that with the current system and enable it by default would require that all nodes end up with an auto-generated name (e.g. "n0" or "node0"), which, again, would be fine with me.  I was suggesting in the patch I posted earlier that this could be controlled by a global flag, which if we wanted to preserve the existing API, would have to default to on.

Tom