[DISCUSS] Change the semantics of "getDriver"?
Hi all, while working on streamlining the API and making it more tool-friendly, I added a "listDrivers" method that returns the codes for all drivers currently registered in the DriverManager. I noticed that we have a "getDriver" method, that accepts a full url. However it's only interested in the scheme part of the URL. Would you have any objections to me changing this to "getDriver" being defined on the "code" only and to add a "getDriverForUrl" to take over the function of the current getDriver" implementation? Chris
[DISCUSS] Discover and Browse API for PLC4J?
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
Re: [DISCUSS] Extend our Jira Issue format to allow selection of "component" and "language"?
+1 From: Christofer Dutz Reply: dev@plc4x.apache.org Date: June 30, 2021 at 05:25:51 To: dev@plc4x.apache.org Subject: [DISCUSS] Extend our Jira Issue format to allow selection of "component" and "language"? Hi all, as we are more and more polyglot, the question of "What language does br/>this apply to??" comes up more frequently. So how about adding this as a br/>mandatory field in issues?? Chris
Re: [DISCUSS] Extend our Jira Issue format to allow selection of "component" and "language"?
+1 Am Mi., 30. Juni 2021 um 11:25 Uhr schrieb Christofer Dutz < christofer.d...@c-ware.de>: > Hi all, > > as we are more and more polyglot, the question of "What language does > this apply to?" comes up more frequently. So how about adding this as a > mandatory field in issues? > > Chris >
[DISCUSS] Extend our Jira Issue format to allow selection of "component" and "language"?
Hi all, as we are more and more polyglot, the question of "What language does this apply to?" comes up more frequently. So how about adding this as a mandatory field in issues? Chris
[jira] [Created] (PLC4X-302) [KNX][Go] Possible isolation issue in KNX driver
Christofer Dutz created PLC4X-302: - Summary: [KNX][Go] Possible isolation issue in KNX driver Key: PLC4X-302 URL: https://issues.apache.org/jira/browse/PLC4X-302 Project: Apache PLC4X Issue Type: Bug Affects Versions: 0.9.0 Reporter: Christofer Dutz When executing a "discovery" (SearchRequest to the Broadcast address) multiple responses can come back. In the case of some code we use at Mapped, however I have encountered that the second SearchResponse coming in is being discarded as it seems to go to the defaultHandler of the connection. So in this case the time between the response of the gateway and that of the second KNXNet/IP device is enough for the application to login with the gateway and the second response seems to go to that UDP Port and hereby is handled by the defaultHandler of that connection, which discards the SearchResponse as it doesn't know what to do with it. Also later on in the application, if a new discovery is initiated while the Browse operation is stills scanning the KNX network (Situation only occuring during testing) it seems the connections are sort of messed up as the ConnectionRequests for the new connection go to the handlers of the first connection and get discarded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
