Well the problem with eagerly including transports is: For example, using Modbus ... most transports being used will probably be onls TCP. And with Modbus-RTU it should only work with Serial, but there are people using serial-to-network converters, so you also could use Modbus-RTU via TCP transport ... also, if we ever support passive-mode we would be adding raw-passive. I think initially I made the drivers explicitly depend on the default transports and have people include the optional ones. I think for the raw transports on some systems you needed to run the application as root or with privileged network access.
But admittedly this has been so many years ago .. I don't even know if this is a problem today. My reasoning on using "supported" is that these are the transports we are aware of and explicitly support, if the user uses S7 with Serial for example, that's not "supported" and if he has trouble with this ... well I guess it's his problem ;-) So, what would you be proposing on returning? @Łukasz Dywicki ... instead of returning "tcp" to return "Class<TcpTransport>" (or however we do it)? Chris -----Original Message----- From: Łukasz Dywicki <[email protected]> Sent: Mittwoch, 19. Januar 2022 11:47 To: [email protected] Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"? I come over this issue yesterday, but on other end. While trying to get 0.10 running under OSGi I found that "wiring" if fine but whole thing fails to work at runtime. This boils down to several things, but Transport SPI lookup too. I agree that listing supported transports types (tcp/udp/serial/can) is fine for start. On other hand it is unlikely we will ever get S7 working over serial line so we could in theory declare that it works only with TcpTransport. Later one is actually beneficiary, at least for OSGi, cause it makes S7 driver classpath aware of TcpTransport requirement. This was issue Etiane was facing back then while working with Camel components to wire everything in. Anyhow, I am fine with both, with some level of preference for listing transports directly. If we scope dependencies properly end users will get drivers working out of the box with very few entries in their build tool. Best, Łukasz On 19.01.2022 10:44, Christofer Dutz wrote: > Hi Cesar, > > right now, I would only like to give back a list of strings that are the > codes of the supported transports. > Perhaps we should extend the transports to give tooling more assistance on > how a given transport is to be configured. > > Chris > > > -----Original Message----- > From: Cesar Garcia <[email protected]> > Sent: Sonntag, 9. Januar 2022 17:29 > To: Apache PLC4X <[email protected]> > Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"? > > How are they? > > Not only the transport, but also the data structures of the items. > > This would allow the user to have a reference of what you can request in the > items. > > Looking to the future, this would be a must for the OPC-UA server. > > Kind regards, > > El dom, 9 ene 2022 a las 6:10, Christofer Dutz > (<[email protected]>) > escribió: > >> Hi all, >> >> I know initially I built the Plc4X API to generally allow any form of >> driver to use any form of transport. >> However, this only would have worked in theory. >> >> I think we should probably have every driver provide a list of >> supported transports. >> This would also help make tool integration easier. >> >> If we see that for example sometimes, we have ModbusRTU passed along >> TCP/UDP connections via serial-to-ethernet adapters, we can >> definitely support that and if we come across a mode of operation, >> that we haven't encountered, it should be easy to extend. >> >> But this way we could ensure that we build the drivers in a way that >> they know what to expect. >> >> What do you think? >> > > > -- > *CEOS Automatización, C.A.* > *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, > AV. RAUL LEONI, SECTOR GUAMACHITO,* > > *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. > César García* > > *Cel: +58 414-760.98.95* > > *Hotline Técnica SIEMENS: 0800 1005080* > > *Email: [email protected] > <[email protected]>*
