Implementation of ObjectMap, to add a map to the attribute system instead of a vector

[Mathieu Lacage, 2011-07-06 23:17:22]

what exactly is the rationale for this proposal ? i.e., what are you trying to
use this for ?

[Jaume Nin, 2011-07-07 09:42:27]

Dear Mathieu,

The simple rationale behind this is that in LENA we had several maps that
needed to be available through the attribute system to use the trace/sink
feature. In a general context, when we could not use a vector because the
indexs were not consecutive, we used a map<uint_32, ns3::Object map> as a
container

A more down to Earth example is LTE bearer identification. On a given cell,
each UE is uniquely identified by a parameter, C-RNTI. At the same time,
each active bearer in a eNodeB is uniquely identified by another parameter,
L-CID and a given UE can have several L-CIDs. All this is structured in a
nested map fashion, both in the eNodeB and the UE so the paths in the
attribute system look something like this:
/NodeList/#NodeId/DeviceList/#DeviceId/LteEnbRrc/UeMap/#C-RNTI/RadioBearerMap/#LCID/LteRlc/RxPDU

Basically, the ObjectMapValue attributes are used in lte-enb-rrc and
lte-enb-ue to create enable access to certain traces. You can get a better
idea looking at the implementation in
http://codereview.appspot.com/4626069

Hope this clarifies the rationale :)

If you have any other question, don't hesitate contacting me again.

Kind regards,
Jaume Nin

On Thu, Jul 7, 2011 at 1:17 AM, <mathieu.lacage@gmail.com> wrote:

> what exactly is the rationale for this proposal ? i.e., what are you
> trying to use this for ?
>
>
http://codereview.appspot.com/**4644042/<http://codereview.appspot.com/4644042/>
>

[Mathieu Lacage, 2011-08-10 15:50:44]

The implementation looked way too much like a copy/pasted version of
ObjectVector so I refactored the code in ns-3-dev to make room for a new
ObjectMap thing. Please, test ns-3-dev and add relevant tests in
src/core/test/attribute-test-suite.cc.