[Ns-developers] Different Approaches to Default Values (wasRe: Default Values)

[craigdo@ee.washington.edu]

[ ... ]

> One thing I wanted to point out before this idea of a 'global' config
> space goes much further is that it is most likely quite incompatible
> with the idea that our objects are _dynamically_ aggregated and that
> they don't know each other. i.e. /nodes/*/tcp/ is a namespace which is
> created by the user when he aggregates a tcp stack to a set of nodes.
> So, unless you decide to hardcode somewhere knowledge about the way
> objects are expected to be aggregated, you won't be able to build the
> 'global' config namespace or, if you can build it, you won't 
> be able to
> read from it because objects won't know where they are within this
> global namespace so they won't be able to read their values 
> from there.

It's not a pretty picture, but I included it just for the sake of
completeness.

> > Another way to do this is to package this information up into blobs
> > (Parameters) and pass them down into the system.  

[ ... ]

> ok. I think that this 'vector of parameters' can be made to 
> look vastly
> nicer from a syntactical perspective. But, this is a disgression.

I'm sure we can make it look nicer.  I wasn't particularly worried about
that yet.

> > Another way is to use a framework approach.  

[ ... ]

> Ok. So, in the specific case I outlined, you are suggesting 
> that we ask
> the user to subclass the HierarchicalMobilityModelFramework 
> to provide a
> CreateParent and a CreateChild method and that he should pass 
> this class
> to the topology helper classes ? I am perfectly fine with this: I
> suspect that this Framework class could be trivially renamed 
> to Factory,
> hence making its purpose clearer. 

Yes.  That is essentially it.  I like the idea of renaming these things
Factories since framework is a relatively esoteric term.

> What is interesting is 
> that, once you
> are there, the difference between the Parameter stuff and 
> this explicit
> base factory class is that the Parameter stuff gives you a data-flow
> approach to build the factory while what you are proposing is a
> code-flow approach to build the factory.

Well, I would use the term data-driven instead of data-flow since I'm have
some roots in computer architecture, and data-flow has a subtly different
meaning to me; but I understand what you are saying and I think we are on
the same page.

[ ... ]

> > Unless I am missing something, it [a framework] is much easier to deal 
> with.  But I am
> > perfectly willing to hear that I have missed something completely.
> 
> I don't think that the two are fundamentally incompatible: the
> inversion-of-control is clearly necessary to handle the use-case I
> described. What I am trying to do with the Parameter proposal is to
> allow the user a way to easily implement a 'factory' with a data-flow
> approach. So, the latter approach can be quite naturally 
> built on top of
> the basic inversion-of-control framework/factory thing.

okay.

> I sense the start of a convergence here. (fingers crossed)

(was that a plus sign or a sign of the cross? :-)

I see the parameters work as it relates to typeinfo as integral to a simple
"local namespace" mechanism reusing the tracing namespace.  I can also see
how you could use parameters to get configuration information into refined
framework/factory methods in a reasonable way.  The thing that causes the
hairs to stand up on my neck is plumbing the Parameter structures all
through the system to get them down to the lower levels and ensuring they
are consistent, not overwritten unexpectedly, etc., then parsing and using
them in a generic way.

I suppose it couldn't hurt to have two different kinds of tools available
here, although one of the big complaints I hear about Windows interfaces is
there are many ways to do pretty much anything in the system and that can
get confusing and irritating.

Regards,

-- Craig