Node monitor (extended subscription)

[kung-foo]

This PR creates a new NodeMonitor struct for creating managed subscriptions. It attempts to hide implementation details from the user, and provide a simple, high-level interface for interacting with data change events.

see related discussion: #240

The example code shows the two different methods for a subscription: callback-based, and channel-based.

[kung-foo]

There are some naming/structure issues I'd still like to resolve. Possibly merge NodeMonitor and Subscription into a single struct and move Subscribe(...) and ChanSubscribe(...) to package level functions (both returning the new, unified struct).

[magiconair]

This looks like a good start. Maybe call it monitor.Subscription instead of monitor.New. We might have other monitors. I'll need something that reads a list of nodes on a regular basis and that would fit in this quite nicely (e.g. monitor.Nodes).

Do we have to support both channel and callback mechanisms? Wouldn't channel be enough?

Also, you can add nodes as strings and NodeIDs but when you set up the monitor you can use only strings. Don't have a good idea on how to solve that right now but might be something to keep in mind. With Channel and Callback you potentially get four different combinations.

You probably don't want to panic when the subscription id doesn't match ... :)

[kung-foo]

Thanks for the feedback. Regarding chan v callback, my favorite APIs are the ones that usually provide both. From this somewhat hyperbolic article: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/

[...] your API can always be more general, always more flexible, and take drastically less resources if you use callbacks instead of channels.

[kung-foo]

I should point out that the current callback implementation is actually less performant the the channel method because the callback code uses a channel behind the scenes. However, that could be removed with a little bit of work.

[magiconair]

does this refer to the more browsing branch or something else?

[kung-foo]

yes. though I haven't tried it on this exact use case. So it is possible that I can't get access to the single diag node. Also, I noticed that with the FreeOPCUA server, no diag nodes are generated. Is there a standard way to indicate that that feature is not supported?

[magiconair]

I don't know.

[magiconair]

@kung-foo are you using this code right now or are you planning on using it?

[kung-foo]

Yes, we are using it, though not in production.

[magiconair]

How did you find the timer leak?

[kung-foo]

re the timer leak: manual inspection. I just happen to remember that "idiosyncrasy" of the timer API.

[magiconair]

@kung-foo How far are we from merging this? I'd like to start using it.

[kung-foo]

I think we are good to merge. We can re-visit features like reconnecting to a subscription in a future PR.

[magiconair]

Then lets do it.

[fdamador]

Thank you for creating the monitor code which i've been testing.

I have a need to pass the msg.value.value() values data back to my own custom struct array I have in the main() routine for a series of NodeIDs. Can I do this by interrogating the subscription server? Or do I have to send the NodeIds data (time, value, quality, etc) via channel?