Thoughts on extending v params to other objects?

1

I love V-Params, they help to abstract away all the cruft to work around vendor extensions.

@zaidka, what are your thoughts on extending V-params to allow them at any point in the object graph?

Here is my use case, I have to check the instance of a host in (IGD.LANDevice.{}.Hosts.{}) for 3 different keys (X_CLEARACCESS_COM_WlanRssi, X_COMTREND_AssociatedDeviceSignalStrength, X_ZYXEL_RSSI) to get the RSSI for a wireless device. Because this value exists on a per host instance, using a conventional v-param won’t work real cleanly (unless I go through gyrations with serializing json/csv data).

2

Agreed. This would be a great feature to have. The implementation is incredibly difficult to get right though. There’s a somewhat related feature that I’ll start working on soon which is to abstract out the data model implementation and isolate the TR-069 protocol into its own component (to allow supporting other protocols). It is my hope that having that in place will give me a framework in which nested vparams can be implemented.

How do you propose the user should define the dynamic vparam instances?

3

I hadn’t thought that far ahead honestly… and I kind of figured implementation would be a pain to get right and not introduce a lot of heisenbugs.

I’ll do some cogitating and try to come up with a reasonably simple approach to define dynamic vparams.

-dan

4

Last year I wrote a tool that acts as a bridge to translate other protocols into TR-069. I faced a similar challenge where you need to define a custom (and dynamic) data model. The way I approached it can apply here. This is what the data model definition looks like:

const dataModel = {
  "InternetGatewayDevice.DeviceInfo.SerialNumber": {
      value: getSerialNumber,
      writable: true
  },
  "InternetGatewayDevice.Domains.*.DomainName": { value: getDomainName },
  "InternetGatewayDevice.Domains.*.IPAddress": { value: getIpAddress },
  "InternetGatewayDevice.Domains.": getDomainInstances
};

This is for a sample protocol implementation where the “device” is a DNS record. As you can see the key/path (akin to vparam name) can contain an asterisk. This tells the engine what function to call when there’s a request for parameters matching the given pattern. This approach works fairly well but I have three issues with it:

  • You need to be careful not to have overlapping patterns (e.g. “a.*.b” and “a.1.*”)

  • Since every param is its own function call, it can cause a lot of redundant processing in situations where multiple params can be fetched using a single request downstream. For example, in the example above you can fetch the IP and domain name with one call, but you can’t take advantage of that fact because every parameter is independent.

  • The function for returning available instances has a different signature than the value functions. I’m not comfortable with that and feel it can be simplified somehow.

Let me know your thoughts.