[Ns-developers] [ns3] topology API

[craigdo@ee.washington.edu]

Hi all,

I've been reading this thread and the direction in which it's going with
great interest.

A couple of days ago, Mathieu wrote an email in which he observed that there
is a kind of data-flow control-flow distinction that is really needed here,
and spoke about how GUI systems address similar problems.  I agree with
those observations wholeheartedly.

We've been developing Joe's canonical example and I've seen "helper" classes
begin to appear with pieces that include for-loops and other such code that
will probably be unlikely to change.  I've seen functions that the user is
expected to change in order to specify new kinds of objects down in the
bowels of the system.

You know, there is an approach that has been used to address this kind of
design challenge many times.  It's called a software framework.

I think that a case could be made that the for-loop kind of stuff we've been
discussing maps nicely to framework "frozen spots" and the mechanism Mathieu
talks about to "delegate the object creation to the user" maps nicely into
framework "flexible hot spots."  The technique used to expose how to create
those objects way down in the bowels of the system is called
inversion-of-control.

I've written quite a bit about frameworks, how they work, and how they might
be used in situations that are almost identical to those we're describing
here.  I'd like to revisit that technique since it appears that we finally
have developed ns-3 scenarios to the point where frameworks won't look like
silly pointless overhead.  It's been a long time since we talked about this
stuff seriously -- are there any requests for background information on
frameworks and their possible ns-3 applications before I just jump in and
start dumping out possibly quite unfamiliar terminology and mechanism?

-- Craig