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
