Fix broken support for 'transport' connection option
Review Request #4083 - Created Feb. 28, 2012 and submitted
Previous unification of URL support broke the ability to supply the 'transport' (e.g. tcp, rdma, ssl etc) on a connection. This can still be supplied in the URL itself if the 0-10 URL format is used but the regression should be fixed. The change in this patch adds a method to the Url class to parse a string without populating any resulting addresses with TCP as the default protocol if none is specified. This allows the protocol in the Address to indicate what was explicitly provided and lets the decision on defaults be taken elsewhere (in this case in the underlying client API).
New case added to sssl tests that uses a mixture of url and connection-option. Make check passes.
Posted (Feb. 28, 2012, 2:21 p.m.)
I would suggest something like this: parse(str, defaultProtocol=Address::TCP) URL(str, defaultProtocol=Address::TCP) That's backward compatible and lets you set the default protocol to whatever you like when you are parsing the URL. The problem I see with leaving the protcol unspecified is that the URL may be interpreted in a different context from where it was created and get a different default protocol from what was intended.