Hi!
On Tue, 2020-01-07 at 14:05 +0000, Christofer Dutz wrote:
> 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}
>
For me is a natural extension for the current connection string and it
is easy to understand it. so +1!
> 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
>
>
