[Ns-developers] [ns3] topology API

[craigdo@ee.washington.edu]

> Honestly I don't see the point od TopologyFramework::Build (uint32_t n).
> It's not like a for-loop is _that_ complex, even in C++.  And I think
> TopologyFramework::Build just obscures the simple for loop.  And if 
> you start making examples with TopologyFramework::Build then some
> people will think that TopologyFramework::Build does some kind of 
> special magic to make it happen and will forever be afraid to do a 
> simple for loop. 

Well, the whole idea behind topology generation is that the client doesn't
have to write the for-loop, or the mass of other boiler-plate code that is
likely going to be in non-simplistic real topology code.

What the Build method hides is all of the grunt work.  I don't particularly
like the idea of writing bunches of code every time I do something similar.
That whole concept drove the idea behind frameworks (and design patterns in
general) in the first place.  I've used frameworks and I can still write
for-loops.  I've used lots of system libraries and I can still write
for-loops.  I prefer not to write file systems, whenever possible, though
:-)

It's hard to illustrate something like a framework with examples simple
enough to demonstrate their usefulness; just as its hard to illustrate
something like a library without having something significant enough to
demonstrate their usefulness.  Perhaps the person who first proposed a
library heard, "what's with all this linker crap; why don't you just copy in
the code, some people will think that something magic is happening and
people will forever be afraid to write string comparison functions."

Anyway, you seem to think that a topology framework doesn't do anything
useful.  From my perspective it does very useful things:

- Provide a simple, consistent, easy to use way for a client to create a
complex structure of complex objects using a single method call;
- It allows us to use our simple component substitution mechanisms to change
the complex objects created without programming;
- It presents a consistent, easy to use model for getting down into the
depths of the system and allowing us to tweak the control-flow directly
instead of having to plumb control-flow descriptions (Parameters) throughout
the system.
	
> I like the idea of container/group much better; at least 
> a container does something useful: keep a list of nodes.
> I don't think inversion of control is beneficial in this 
> case because it only automates a simple for loop.  And if
> a new API is not beneficial it ends up being harmful 
> because you have to learn it anyway. 

Maybe you could see my point of view better if you thought of a design
pattern or idiom.  Are design patterns useful?  Are STL queues useful?  They
are often just APIs to automate simple for loops and trivial data
structures.  Why should you have to learn them?  Well, because they really
*are* useful.  These things are useful because they are solutions to
problems that work, have been proven to work, and have most of the grunt
work done for you.

Just as a design pattern is a generic repeatable solution to a common
problem, the topology framework is intended to be a generic solution to a
common topological problem.  Clients don't have to solve the problem over
and over again.  They just look up the framework that solves their
particular topology problem and work with it.  Regarding the "frameworks
considered harmful" view, I have a hard time believing that if you use a
Singleton design pattern (which is basically just an if statement or a
static keyword), you'll forget what an if statement is, or what a global
variable is and how to declare and use them.

The nice thing about design patterns and frameworks is that they are known
to work (someone has usually put some hard thought into them) and they can
be reused easily.  If we end up with 50 different stock topologies, it would
be nice if they all worked pretty much the same way (same conceptual model)
and reused as much code as possible.  I wouldn't want to see 50 different
authors writing 50 different for-loops in slightly different ways with 50
slightly different ways of calling them.  I especially wouldn't want 50
different solutions that did the same thing.

By the way, the little bit of pseudocode I provided did use a
container/group.  That's what it built for you.  The challenge for us will
be to make sure that the frameworks (generic solutions to the topology
problems) that also allow you to have access to the innards of the code when
you need it are going to work and play well together.  I believe there will
obviously be more to a framework than a for-loop.

Regards,

-- Craig