[Ns-developers] [ns3] topology API

[Mathieu Lacage]

On Tue, 2008-01-15 at 09:38 -0500, Joseph Kopena wrote:
> On Jan 15, 2008 3:23 AM, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> >   - construct multiple objects in one go. For example, the WifiHelper
> > class can create the RateControl object for you and assign it to the
> > associated WifiNetDevice.
> 
> So, I think then the question is: How much can the WifiHelper be
> abstracted such that it becomes the swappable point for creating
> different networks?  For example, maybe it's not WiFiHelper, but

Well, if someone designs an API which is sufficiently close to the
WifiHelper API for another kind of NetDevice, then, it probably would
make sense to add a base class with this shared API to allow hot
swapping. Are we there yet ? I don't think so :)

> WiFiAdHocHelper & WiFiManagedHelper, both of which have the same
> interface & can be hot swapped.  There are definitely some issues
> there---ad hoc & managed wifi are fundamentally different in that the
> latter needs to choose or create an access point, and similarly
> they're both fundamentally different from P2P via broadcast ability,
> but that's maybe not insurmountable.  It might also not be necessary.
> If this sort of thing is a total disaster resulting in huge object
> model discussions, maybe it's ultimately easier to write several very
> similar simulation scripts rather than have a really flexible,
> run-time changeable sim creation API; let the users build their own
> ad-hoc structures to implement their needed flexibility.  Ultimately
> they're going to do that anyway if the built in system is too complex.
>  This does not change the need for the ability to configure "deep"
> internal paramaters though, like the TCP window size, WiFi retry
> limit, etc...

I can't agree more with this latter comment on the need to let users
build their own things to match their own special needs.

> I'd also like to second Gustavo's note that I find APIs more
> accessible that have less functions & more values to those functions.
> That way at least there's a single place to look for all the things it
> can do.  For example, I find it nicer to have a Set(param, value)
> function rather than SetParamA(val), SetParamB(val), SetParamFoo(val)
> suite.

This is clearly a matter of taste: a generic Set method can work only if
there is extra very detailed documentation about the allowed name/value
pairs but if you have this documentation, it is really the same. 

I tend to like the SetFooA version because the API is partly
self-documenting but I don't feel very strongly about it: I don't think
we are talking about 100 setters but more something close to 10 to 20
setters which seems manageable to me.

regards,
Mathieu