The good thing with this would be that we could support passive mode, capture and replay with the normal drivers without adding hard dependencies on pcap4j and libpcap. We would add compile scoped dependencies to the default transport but optional ones for the others.
The more I think of it, the more I like it. Chris Am 07.01.20, 15:05 schrieb "Christofer Dutz" <[email protected]>: 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
