Hmmm odd … usually my outlook doesn’t do that… but I’ll be more careful about it.
What do you mean with “optional” flag? In maven you can declare a dependency as optional, do you mean that? If that would work, that would be great. As I mentioned, so far I was planning on using the “optional” maven dependencies, but didn’t do that yet. Chris From: Łukasz Dywicki <lukasz.dywi...@connectorio.com> Sent: Mittwoch, 19. Januar 2022 13:24 To: dev@plc4x.apache.org Cc: Christofer Dutz <christofer.d...@c-ware.de> Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"? Chris by accident sent answer to me (we both love Thunderbird for that). ;-) There is a bit of risk with listing all transports as for modbus as we will effectively end up with tcp, serial and udp (at some point, who knows what else?). ;-) I need to check how optional runtime dependencies gets propagated by maven, maybe we could reduce impact on downstream projects by optional + scope markers. From OSGi point of view we need to update metadata to list compatible transports using "optional" flag. I could do that in 0.10 as this is something I found problematic with prior releases. Other way is using constructions such as "require-capability: plc4x-transport;kind=tcp", but this gets us on complicated path which I don't think we need nor will be able to fully utilize in coming year. Best, Łukasz On 19.01.2022 12:00, Christofer Dutz wrote: 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 <l...@code-house.org><mailto:l...@code-house.org> Sent: Mittwoch, 19. Januar 2022 11:47 To: dev@plc4x.apache.org<mailto:dev@plc4x.apache.org> 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 <cesar.gar...@ceos.com.ve><mailto:cesar.gar...@ceos.com.ve> Sent: Sonntag, 9. Januar 2022 17:29 To: Apache PLC4X <dev@plc4x.apache.org><mailto:dev@plc4x.apache.org> 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 (<christofer.d...@c-ware.de><mailto:christofer.d...@c-ware.de>) 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: support.aan.automat...@siemens.com<mailto:support.aan.automat...@siemens.com> <support.aan.automat...@siemens.com><mailto:support.aan.automat...@siemens.com>* -- Łukasz Dywicki Chief Executive Officer luk...@connectorio.com<mailto:luk...@connectorio.com> [Logo]<https://connectorio.com/?utm_source=mail_logo> Krasiczyńska 3 m.80 03-379 Warsaw, Poland Mobile +48 721 151 666 www.connectorio.com<http://www.connectorio.com/?utm_source=mail_link> [Facebook icon]<https://www.facebook.com/connectorio> [LinkedIn icon] <https://twitter.com/connectorio> [Twitter icon] <https://twitter.com/connectorio> The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
