feat(client): Allow modifying the connect destination

[kpcyrd]

This resolves #1564.

As far as I can tell, this is a non breaking change that could be released in a 0.0.X upgrade. Please let me know if you prefer a different implementation. :)

[seanmonstar]

Thanks for starting this up!

This may be the simple way forward, I just want to discuss the pros and cons. In this case, a user can construct a Uri themselves, and then easily set it. What happens if they did so without a scheme or authority? dest.set_uri(Uri::default() would set it to /. Is that a problem? Should other connectors be able to handle empty string for scheme and host?

A possible alternative is to take a string instead, fn set_uri(&mut self, s: &str) -> Result<(), hyper::Error>. This could require absolute URIs, and return an error otherwise. But maybe it's fine to make connectors have to deal with empty strings.

Thoughts?

cc @sfackler

[sfackler]

The fact that there's a URI inside of the Destination is currently an implementation detail, so I'd expect just pub fn set_host(&mut self, host: &str) -> Result<(), Error> and pub fn set_port(&mut self, port: Option<u16>).

[seanmonstar]

I like that. Is there a good use for having set_scheme as well?

[sfackler]

I can't think of one off the top of my head, but it seems like we might as well be uniform with the setters.

[kpcyrd]

There are no setters on Uri, if the api allows modifying parts of the Destination, should I try to build a new Uri with the value provided? Is there a way to ensure a Uri meets all requirements of a a valid destination?

[seanmonstar]

You can convert the current URI into it's parts, and then you can parse the new one and insert it, and try to convert back into a URI. If it's illegal, that should return an error already.

[seanmonstar]

I wrote the suggested changes up over in #1572.

[kpcyrd]

@seanmonstar awesome, thanks! closing in favour of #1572