[Ns-developers] [ns3] topology API

[craigdo@ee.washington.edu]

> Craig,
> I like this model for possibly building some topology or 
> scenario code. 
>   However, I am not sure that we want the whole bowels of the ns-3 
> system inverted for such access.  In the example you posted, we are 
> talking about asking users to write:
> 
>    Ptr<NetDevice>
> MyWirelessClusterFramework::CreateNetDevice (Ptr<Node> n, 
> Ptr<Channel> ch)
> {
>    Ptr<WifiNetDevice> nd = CreateObject<WifiNetDevice> (n);
> 
>    Ptr<CraigsWeirdRateControl> rate =
>      CreateObject<CraigsWeirdRateControl> (param1, param2, param3);
> 
>    nd->SetRateControl (rate);
> 
>    return nd;
> }
> 
> where presently they could write something like:
> 
> DefaultValue::Bind ("WifiNetDevice::RateControl", 
> "CraigsRateControl");
>
> if the constructors matched.

Well, this is explicitly the case we've been discussing where the
constructor for CraigsWeirdRateControl has different parameters than
MathieusNormalRateControl object so they couldn't just do what you suggest.

But in the case where the constructors do match, I said that we should keep
the substitutability mechanism, as you observe later.  It's a simple
non-programmatic way to change behavior which I think is very useful.  I
would use a "normalized" version of DefaultValue::Bind that fits in with the
unified tracing/configuration system to do what you say.

> My main concern about delegating object creation to the user in every 
> case is that we seem to be losing the capability for such 
> simple APIs as 
> above for modifying the construction of composite objects like 
> InternetNode and NetDevice.
> 
> But it seems in your most recent post that you are suggesting 
> some kind 
> of middle ground where both a component manager and inversion 
> of control 
> could be applied where needed:

Exactly.  Use a component manager when it's easy (make simple things simple
to do) and use inversion of control when things are more dicey (make complex
things possible).

>  > - Leave the ability to substitute "components" in simple 
> cases (i.e.,
>  > "TcpRaj" vs. "TcpReno" in cases where their constructors 
> are default or
>  > identical);
>  > - Use the frameworks approach to bring methods "out from 
> the bowels" 
> in more
>  > difficult situations for greatest flexibility.
>  >
> 
> which appeals to me as well.