Hi Chris,
this was a decidion I made (and therefore exposed as PR).
I think this is a good compromise between many protocols being on TCP / UDP and
the fact that we want to have the "ping" for most drivers.
In fact, I intentionally implemented it as an Optional and stated in the JDoc
that a non TCP / UDP Driver should return Optional.empty().
Do you agree with that?
Otherwise, we can of course plan to implement it differently but then it gets
more and more tedious and perhaps we are missing something in driver
implementations.
Julian
Am 01.04.19, 10:06 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi all,
today I simply have a little time to inspect the latest changes as I was
travelling for 5 days …
I do have a few questions:
Why is AbstractPlcConnection been extended by a getInetSocketAddress method?
PlcConnections are not bound exclusively to TCP/UDP … we currently already
have Serial port based connections and when going into protocols like Profinet
and EtherCat in the future we’ll be going down to IP or even Ethernet level.
I don’t like TCP/UDP details in the base abstract class for all drivers.
… continuing to evaluate …
Chris
