Hi folks, for the past weeks I have been thinking about how we could approach the “discovery” topic.
I think I just had an idea and would like some feedback from you. So I was thinking about how we could model such a discovery API. In general it would look pretty different to the existing APIs … at least I thought. The Idea I just had, was: How about we create a new “discovery” driver? This can use both the serial transport as well as the passive-mode transport or even tcp transport for protocols that allow active discovery mechanisms. So you would simply create a “connection” to something like “discovery:raw//eh1” or “discovery:serial:///dev/ttyS0” … now this driver would be a little special. It would internally query the list of drivers available on the given system, the same way the DriverManager does it. But it would check each driver if it implements an interface “SupportsDiscovery” (or whatever name we give it) … So it would then initialize an instance of all drivers supporting discovery. So in the end the DiscoveryDriver would simply try to feed each packet to each of the drivers and have them check if they can make sense out of that. If they do, they would start emitting events just the same way a resource subscription does. (Of course we should probably apply some filtering mechanism to avoid too much overload) So a client wanting to use discovery, would use the normal PLC4X API to connect and then would simply subscribe to the datastream produced by that. So in the end we wouldn’t be changing anything with the user-facing API and all could be done internally … and the cool thing we would get all the integrations working with this without modifications for free :-) … so you could start simply streaming the discovery data to StreamPipes or Kafka or log it in IoTDB for intrusion detection or other crazy stuff What do you think? I have to admit I am currently absolutely happy with this idea … so please … bombs away … tear it apart ;-) Chris
