I'm just thinking of more complex situations. If you want a tls connection you need a TLS login, that contains the certificate.
With the secure ams case it gets more complicated. Here there are two variants of certificate based login (self signed and "official") or psk. But self signed ads psk needs a login too... So the protocol requires one and the transport also. So if the PskTlsTransport requires PlcAuthenticationPskTls and the driver needs AdsPlcAuthenticationPskTls which extends the simpler one. I'm also more thinking about how to integrate plc4x in this party applications such as Nifi, Camel, StreamPipes... Does that make sense? Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> ________________________________ From: Łukasz Dywicki <[email protected]> Sent: Saturday, February 21, 2026 9:48:36 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Add information about the used Protocol and Transport to the PlcConnection MetaData? It sounds like a good idea, however its not entirely clear what would be use of it. In the end user knows URI before hand, so he should be able to process this information. I agree that its better to normalize information on our end, but don't see a clear use of it. With JDBC the connection metadata have a lot of various elements, including product name, driver name, version and so on. Best, Łukasz On 2/20/26 15:02, Christofer Dutz wrote: > Hi all, > > I’m currently working on polishing the ManualDriverTest functionality and > wanted to output the name of the driver and the used transport name at the > end and noticed that we don’t expose that information. > > I think this is not controversial … just wanted you to know that I’ll extend > the Metadata to include the protocol code, protocol name, transport code and > transport name in the PlcMetaData. > > Hope you agree? (If not’s it’s easily revertible) > > Chris > >
