+1
Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: [email protected] Web: http://www.isw.uni-stuttgart.de -----Ursprüngliche Nachricht----- Von: Christofer Dutz <[email protected]> Gesendet: Tuesday, January 7, 2020 3:06 PM An: [email protected] Betreff: Taking the transports generification one step further ... Hi all, the more I think of it, the more I think we might even go one step further and provide transport modules with the same mechanism we are providing multiple drivers. Right now we are using a service lookup to load drivers that implement a given interface and are listed in that interfaces property file. Now how about providing a second dimension in this … as we are currently normalizing the way connection strings are built, we could do something like I mentioned in the other email: {protocol-name}:{transport-name}://{connection-url}{property-string} Every driver could provide a default transport name and if the second part is missing that transport is then used. Ideally we’d have a base ConnectionParser, that does all the property-parsing, but transport-specific parsers which do the url-parsing. So the TcpConnectionParser would know how to handle TCP connection strings, while the PcapConnectionParser would know how to read and initialize Pcap transports. What do you think? Chris
