[Ns-developers] ns-3-object proposed for merge

[Tom Henderson]

>-----Original Message-----
>From: Gustavo Carneiro [mailto:gjcarneiro at gmail.com]
>Sent: Wednesday, January 30, 2008 04:25 PM
>To: craigdo at u.washington.edu
>Cc: 'ns-developers'
>Subject: Re: [Ns-developers] ns-3-object proposed for merge
>
>
>
>I could suggest another alternative: AddInterfaceObject and
>QueryInterfaceObject...  Yes, a bit more verbose, I know :P
>
>I should also point out that we could probably use a new API for generic
>object aggregation.  You will ask why.  I will answer that we do not
>currently have the equivalent of a "process" in NS-3.  I am currently
>getting by with the OLSR agent by, well, defining an OlsrAgent
>interface/implementation and attaching it to a Node object via
>AddInterface.  You will ask, why do I need to attach the OlsrAgent to the
>Node object, to which I will answer that I want to bind the life cycle of
>the OlsrAgent to the Node in which it is "running".  By using AddInterface I
>can release my own reference to it and still be sure that the OlsrAgent
>instance will be released when the node is released, but not sooner.
>
>For some time now I have wished for a more generic "process" API.  It does
>not have to be put in the base Object class, but maybe it belongs in Node.
>It should allow a Node instance to manage a set of objects, regardless of
>type (allowing even multiple objects of the same type to be attached).  Now
>_that API_, should we ever add it, will be a _real_ object aggregation.  And
>if we start using AggregateObject/AddObject now then it would be very
>confusing later if we add another type of aggregation.  Of course if such a
>generic object aggregation API is out of the question then this argument is
>void.
>
>Sorry for extending this thread, but I just want the full implications of
>choosing these new names to be clear to all.
>

Gustavo,
It seems to me that we already have something like what you are describing, which is the list of Applications in a Node.   Presently, this Application list is not really used, and we discussed last year that we may want to decouple traffic generators from application objects.  Could the existing Application base class and Node::m_applications be morphed into what you are seeking?  If so, what would the changes look like?

Tom