Repository navigation
ProcessLink() should probably get passed framework.Client #1
Description
Seems like it would be pretty common when linking devices to want to access thinks like the device name and owner string. Passing framework.Client structure, or some reduced clone of it, would make that easier. UnLink probably doesn't matter as much, but might as well make them symmetric.
I'm not sure if they should also be accessible in ProcessMessage(), maybe? The downside would be if people abuse the Client calls it will slow things down. We don't want a REST call for every MQTT message. A warning in the comments might be enough though.
Activity
linux4life798 commentedon Dec 31, 2017
I agree. Not providing an easy way to access the ServiceClient object was a bit of an oversight.
Right, we don't want people to call that FetchDeviceInfo frequently, so I think we should facilitate fetching cached info or something similar.
I needed to make that FetchDeviceInfo seperate and explicit, since it currently DOES require a separate REST call to get that basic device info. Furthermore, it is not guaranteed to succeed after a service link add event.
I propose adding more essential device info to the service link event sent from the REST server. Then, I could add that info to the ProcessLink hander without feeling guilty about adding racey code to a core library. I think we should provide those basic properties to all the handlers. This could definitely simply user code.