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

[Gustavo Carneiro]

On 31/01/2008, Tom Henderson <tomh at tomh.org> wrote:
>
>
> >-----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?


OK, now I am seeing Application with a different angle.  Yes, I think it is
perfect as it is :-)   Probably OlsrAgent should be an Application subclass.

I think what got me confused was that I always thought Application ==
traffic generator, i.e. something rather dumb that only shapes traffic.  I
guess it was due to lack of non-traffic generator examples.  If there are no
objections I propose to make OlsrAgent a subclass of Application.

Regarding AggregateObject/AddObject, well, I am still more inclined to
prefer AddInterface/QueryInterface, but since I'm the only one then just go
on with the rename, so that I can adapt the python bindings after and merge
them...

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