+1 - > I like the
{protocol-name}:{transport-name}://{connection-url}{property-string} this
is really good generification approach. And helps to simplify transports.
Am Di., 7. Jan. 2020 um 15:13 Uhr schrieb Christofer Dutz <
[email protected]>:
> 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
>
>
>
>
>
