• Development
• Blueprints
• adhoccontext

Summary

The use of wns::probe::bus::ContextCollector is too complicated. It is not always needed to use the ContextProviderCollection and ContextProvider to fill context of a measurement. The users needs to write too much code to simply get a local variable transported on the probe bus as context when a measurement is made. This blueprint proposes an extension to the ContextCollector API that simplifies the process. Furthermore, the user does not need to deal with the ContextProviderCollection if it is not needed. The base usage is then reduced to (pseudo-code)

  double MeasurementValue = 1.234;
  wns::probe::bus::ContextCollector cc_("probeBusName");

  cc_.put(MeasurementValue, "IntegerKey", 1, "StringKey", "hello", "MoreKeys", "world", "EvenMore", 1); 

The argument list after MeasurementValue should have a dynamic length. And each key, value pair should be put the the measurements context. Also you do not need to provide a ContextProviderCollection to the constructor of a ContextCollector. If it is not provided an empty collection is constructed by default.

Release Note

The basic usage of wns::probe::bus::ContextCollector is much more simplified. Users are expected to implement their desired probing much faster.

Rationale

The basic usage of wns::probe::bus::ContextCollector is much more simplified. Users are expected to implement their desired probing much faster. One common use case is that you want to add local variables as context to your measurement. If you want to implement this now you need to use a VariableContextProvider and you need to add it to the ContextProviderCollection. For each local variable you want to pass to the probing subsystem you need to have one VariableContextProvider and whenever you do a measurement you need to update that provider by calling its set method.

The implementation effort needed can be very much reduced. The ContextProviderCollection and ContextProviders can be hidden completely from the user if she only wants to supply local variables (or locally available values) as context. The feeling of the ContextCollector's API would be much more similar to that of a logging system, which is understandable quite fast.

Use Cases

Pass local variables (or local known values) as context to the probing subsystem.

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

The implementation uses the boost::tuple library and provides an API as follows. (Note that the put method with PDU is similar).

  double MeasurementValue = 1.234;
  wns::probe::bus::ContextCollector cc_("probeBusName");

  cc_.put(MeasurementValue, boost::make_tuple("IntegerKey", 1, "StringKey", "hello", "MoreKeys", "world", "EvenMore", 1));

All methods are additional methods. The former behaviour is completely preserved. The implementation uses recursive templates. There should be little, to no runtime performance overhead.

API Changes

ContextCollector API is extended and backwards compatible.

Code Changes

The most relevant changes are made in ContextCollector.hpp . There were also some additions necessary in Context.[hc]pp. See the associated branch for details.

Migration

No changes needed. Fully backward compatible.

Additional documentation needed in the developers and users manual.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working.

This need not be added or completed until the specification is nearing beta.

Open Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF ¹; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

• CategoryBlueprint