daniel.moran
daniel.moran
Consider the following scenario with the current functionality (all the operations for the same Entity A and same attribute Attr1): - a Context Provider registers in the Context Broker. -...
After a careful review by @fgalan, a lot of improvement points have been risen for the documentation. # Readme.md - Links to the Installation & Administration Guide and User &...
Current documentation of the functions provided by the library is really hard to read, and some effort should be put on making it more accessible for IoTAgent developers (dividing it...
This issue is about implementing the basic API metrics operations, along with the first batch of counters (the common ones for all the IoTP components). Operations to implement: ``` GET...
Some of the module functions lack of a good JSDoc documentations. This should be addressed, at least for the most important or complicated functions.
The library is having a huge refactor to support the single configuration mode, but no explicit tests have been conducted to ensure proper working of the multiple configuration mode. Those...
Both APIs are closely related and should be cross-linked for ease of use. Documentation should be extended in the relation between both of them (including the "single-configuration-mode" details).
There should be a character check for each of the attributes in a Device Provisioning or Configuration creation. The appropriate check should also be discussed with other parties involved (Context...
The config file lets users configure a default service, subservice and type. I'm not sure those fields have any meaning now, or even if they are being read. This should...
Currently, the IoT Agent doesn't make any duplicity checks on the names that are provisioned via the Device Provisioning API or the Configuration API. The following checks should be done...