Hi all, as you all know, I have threatened to bring API additions from plc4go back to plc4j and now the time has come. But I want to involve you all in it as we all have to live with it ;-)
So in general in go I did it the following way: - I split the topic up into "Discovery" and "Browse" "Browse" I'll focus on as soon ad "Discovery" is defined. In general this should produce a stream of PlcBrowseEvents which provide a stream of PlcField entries that can be used to query information. So this is inside an established connection to a device. It won't find devices (However this term is slightly ambiguous because in KNX for example we consider a KNX devices GroupAddress an address, even if in the physical world it actually is a device) Discovery is the operation of finding out which devices we can connect to. The result is a list of PlcDiscoveryEvents. These contain: - protocolCode (like s7, modbus, ...) - transportCode (like tcp, udp, serial, ...) - transportUrl (which is the part after the "://" but before the "?" - option (which is a map of key-value pairs making up the part after the "?" .... the part which Lukazs hates so much ;-) ) In go I extended the DriverManager to have a discovery function which simply iterates over all drivers it knows and if they support discovery, the functionality is executed. In the past we usually returned a Future and this became complete as soon as the operation was finished. However Discovery can sometimes take quite long. Some protocols support a direct "Please all devices supporting this report to me" functionality, but some we will need to potentially probe by trying all IP addresses in a given range. Therefore I think such a future approach is sub-ideal. In go I gave the discover function a callback argument where you set a handler that gets notified directly as soon as a device is found. I am a bit unsure if this should be the way to go. What I would love to do, would be to have the option to add one (possibly multiple) handlers to a DiscoveryRequest. Whenever something is found, then every handler is called and at the end the result is put into a list. As soon as the operation is complete, the user could then use this list, just like our normal read-results and be happy with it, or he could use the callbacks if he wants to be informed directly. Unfortunately the Futures are so totally all-or-nothing. I would love to return something that knows the progress of the operation. In a Broadcast search it could simply be the progress toward the timeout or when scanning an IP range it could be the percentage of the addresses that were probed. This could help tools to show a nice progress on the auto-discovery. What do you think? As I need this for my work on the PROFINET, I'm working on this on the feature/profinet-chris branch. Chris
