[Ns-developers] finalizing the ns-3 object model (configuration)

[Mathieu Lacage]

On Tue, 2008-01-15 at 09:23 -0500, Joseph Kopena wrote:

> However, this basic Set() idea looks appealing to me, but what is the
> difference versus the current default value scheme?  It's not obvious
> to me.  As it stands, I see the default value names as being somewhat
> unstructured, and this sort of hierarchy could be nice, but that's
> mostly a naming convention.

part of the issue with the current unstructured way of doing things is
that it is hard to figure out which object is impacted by which default
value and in which way it is impacted. Having a more structured approach
really improves documentation.

> My understanding of the Params object was that it added a stack to the
> default values such that you could enable local overrides.  I don't

There are other reasons for going with Param objects:

[extract from an older email]

  - we have default values to initialize object member variables during
construction but no way to enforce that the default values are used only
during construction

  - we have default values to initialize object member variables during
construction but we need to duplicate setters and getters for all
variables once the object has been created.

  - we have ComponentManager::Create but it is hard to use it in a
polymorphic way. i.e., Create needs object-specific arguments so, it is
hard to make the same piece of code create lots of very different
objects which is probably going to needed in some of the Topology
generic code.

  - it is hard to know which objects use which default values. This must
be documented by hand in the doxygen to explain the impact of setting a
default value.


> think the Params object is so terrible, but it's not so awesome
> either.  With mixed feelings about, I put forward that another
> approach would be a global stack manipulator similar to Postscript's
> gsave/grestore, i.e.:

That would be simpler but it really does not solve the same kind of
problems.

> ... set some global parameters in program or console ...
> ... use global parameters
> GSave(); // A new global state is pushed onto the stack, copying the
> previous state
> ... ... set some local parameters
> ... ... use local parameters
> GRestore(); // Global state is popped off, returning to the original
> ... use global parameters
> 
> I'm sort of with Gustavo in that I think strings are to be avoided,
> but I think they'll be ok in this case as long as the Set() function
> is very helpful.  I.e., if you pass in an unknown string, it should
> complain very loudly & obviously (error message & throw an
> exception?), and possibly even report similar strings for double bonus
> points.
> 
> Care should be taken w/ Craig Set() functionality though.  For
> example, if I call this line:
> 
> >   Set ("/nodes/*/tcp/reno/ssthresh", "16000");
> 
> After my simulation is all set up, will it change all the values for
> all the nodes?  That sounds messy to implement, though possibly
> useful.  I'd be mostly concerned about all object using the scheme to

This (accessing all matching nodes) is already implemented in the
tracing subsystem: it needs some generalization to work in this case
though.

regards,
Mathieu