[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 17:14 +0000, Gustavo Carneiro wrote:
>
> >         > 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...
>
> I don't have a definite answer here: I understand your concerns and I
> partly agree with them. I don't like very much either solution myself.
>
> [snip]
>
> >         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.
>
> Yes, I agree. We need to be careful.
>
> [snip]
>
> >         > 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.
>
> Another option is NodeSet.


NodeSet sounds wonderful especially if it's implemented as a subclass of
std::set< Ptr<Node> >; think about it, set operations (union, intersection,
etc.) for free! ;-)

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