plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <j.feina...@pragmaticminds.de>
Subject Re: Some of the latest changes
Date Mon, 01 Apr 2019 08:24:58 GMT
Hey Chris,

I agree and I disagree with you at the same time : )
For specific drivers one should always override the isConnected method (I also updated  the
Javadoc there).
But I see it a bit pragmatic and conclude that "most" of the drivers are tcp / udp based so
I decided that this is "okay".

But of course, it is not absolutely clean, so I agree with a "cleaner" implementation although
I would like to encapsulate it as much as possible to have changes locally.
Perhaps a subclass of the NettyConnection for TCP / UDP?

Julian

Am 01.04.19, 10:16 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:

    The thing is:
    
    If we start implementing the functionality of a "ping" for other protocol types such as
RawIp, RawEthernet, Can, Serial, do we then start also adding "getSocketAddress", getCanIdentifier,
getSerialPortId and stuff like that?
    I think that's a pretty unpretty way to do it.
    
    I'll try to whip up a cleaner implementation ...
    
    Chris
    
    
    Am 01.04.19, 10:11 schrieb "Julian Feinauer" <j.feinauer@pragmaticminds.de>:
    
        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.dutz@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
            
        
        
    
    

Mime
View raw message