[Ns-developers] [ns3] topology API

[Gustavo Carneiro]

On 15/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> On Tue, 2008-01-15 at 13:52 +0000, Gustavo Carneiro wrote:
>
> >         // setup the geographical applications.
> >         c = NodeContainer ();
> >         c.Add (mobility.GetByBoundingBox (NodeList::Begin (),
> >         NodeList::End (),
> >         BoundingBox (0.0, 0.0, 100.0, 100.0)));
> >         application.AddOnOff (c, ...);
> >
> > In the above example shouldnd't "NodeList::Begin (), NodeList::End ()"
> > be "c.Begin(), c.End()" ?  Surely you want to iterate over nodes of
> > the containter, not all nodes...
>
> Well, joseph's use-case was that he wanted to geographically partition
> _all_ nodes.
>
> >
> > This example seems a bit inconsistent.  On one hand you have
> > container.Add (mobility.GetByBoundingBox (...)), on the other hand
> > application.AddOnOff(container, ...), two different styles... which
> > one is it?
>
> I am not really sure I understand this comment: I fail to see what is
> different between these two styles:
>   - GetByBoundingBox returns a NodeContainer and we invoke
> NodeContainer::Add (const NodeContainer & c) to add it to the original
> container.


OK, I completely missed the point of "mobility.GetByBoundingBox" :|
Something doesn't add up.  Why 'mobility.GetByBoundingBox()'?  Shouldn't it
be a function or static method, rather than an instance method?  And what
does it have to do with "mobility"?  So, yes, I agree with the idea, but the
naming is not so good and got me confused.  Yes, I get easily confused, I
know :P

It should have been a GetNodesInsideBoundingBox function, not method.  And
IMHO this sort of API is not needed in NS-3 and can even be distracting.
But, well, apparently I'm the only one who thinks that way, so...

  - ApplicationHelper::AddOnOff does just like every other helper: its
> first argument is a node container.
>
> [snip]
>
> > I see your proposal, but I find it is not as simple as it could be.
> > This expression:
> >
> >   mobility.GetByBoundingBox (NodeList::Begin (), NodeList::End
> > (),BoundingBox (0.0, 0.0, 100.0, 100.0))
> >
> > what does it return?  A list of mobility models, or...?  I think it is
>
> It returns a Node container.
>
> >  simpler to just add a Container.ForEach (Callback<void, Container&,
> > Node&> callback) API, and let the user do whatever he/she likes.
>
> Of course, you want to be able to iterate over the node list if you need
> it. However, GetByBoundingBox is just a conveniance function.
>
> > IMHO the best way to manage complexity is to _reduce_ the number of
> > API entry points, not increase it like it seems to be happening here.
> > The way to reduce API size is to find the optimum tradeoff between API
> > call simplicity and flexibility.
>
> Sure. The goal, here, however, is to provide syntactical conveniance. If
> you want "simplicity", you can use the low-level API.


Fine, but we need to be careful to make sure that NS-3 does not become like
some systems where there is a nice and easy frontend that does common
things, but when you want something less common you have to go to a lower
layer where everything is incredibly complex and unforgiving to small
errors.  In some ways NS-2 is like that: you start softly with oTCL, but to
do real research you have to go to the C++ level and start hacking it.  If
we start relying too much on high level interfaces I am afraid we might
unconsciously start neglecting the intermediate layers because the front end
hides the "uglyness" inside.

I am not saying this  is the case _now_, just something that may happen in
the future, to be aware of.

>
> > We should also think of Python scripting.  Some things, like callbacks
> > and for loops, appear cumbersome  from C++, but are trivial and easy
> > to learn from Python.
>
> I fully agree but we are trying to build a C++ API here.



> Finally I prefer the naming NodeGroup rather than NodeContainer
> > because container sounds like simulating a physical entity that
> > actually contains nodes, while group is obviously a purely logical
> > entity.
>
> I don't really agree but I don't feel very strongly about it.


I don't feel very strongly about it either.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert