[Ns-developers] Current Merge Queue for Ns-3.6 Release

[George Riley]

>
> Maybe there is no philosophical discussion to have (I haven't seen a
>> response to George's post here:
>> http://mailman.isi.edu/pipermail/ns-developers/2009-September/
>> 006555.html
>> and no one else has publicly reviewed this patch set)
>
> Well, I haven't responded because it seems like it would result in a  
> long
> discussion about the direction to take in designing helper "stock  
> objects."
> I don't like the current approach very much
> (PointToPointHelper::InstallStar) and I would like to also reopen a
> discussion about helper base classes as well.
>
> I think we need to talk about this stuff, but IMO this isn't  
> something that
> is going to be resolved in a few days, so I am holding my peace for  
> now.
I agree we need to resolve this, but not before this release.
>
>> These are the two main issues I would like to see handled
>> with the helpers:
>>
>> 1) add support for IPv6 (will we be overloading existing methods or
>> changing method names?)
>>
>> 2) resolve how animation coordinates are to be stored in
>> helpers/nodes,
>> if at all.  BoundingBox () to me seems to be a method more
>> appropriate
>> to give to the AnimationHelper than to each topology object.  For
>> instance, something like:
>>   - AnimationInterface::BoundingBox ()  // sets bounding box
>> for whole
>> canvas
>>   - Dumbbell::CanvasLayout (..) // assign canvas coordinates to
>> dumbbell objects.
>>   - rename NodeLocation aggregated object to CanvasLocation
>
> It seems to me that the simulator proper shouldn't know or care about
> bounding boxes on rendering canvases.  It seems to me that the  
> simulation
> part should only know about the physical positions that are being  
> simulated
> and the animator should be responsible for projecting those  
> positions onto
> its canvas.  If the spatial positions need to be constrained in some  
> way,
> then they should have their simulated physical position constrained.
Sorry Craig but I disagree; our beautiful design is such that any  
Object can have aggregated
to it any other object without regard to the functionality of the  
aggregated
object.  Are you saying you object to me doing exactly this?  I'm  
having trouble
imagining an objection to using our object system as designed.  If you  
don't
want node locations associated with your nodes, then don't include them.
Problem solved.


>
>> But since it is late to agree to this, if we put these in src/contrib
>> for this release and flagged the helper API as being
>> provisional in the
>> provided example scripts, I think we wouldn't be too disruptive to
>> future users, so it seems a suitable compromise to me.
>
> Yes.  I thought we had previously agreed that this was the best  
> approach for
> now.
>
> -- Craig
>
>
>