Any plans to refactor the "Query" and "Lookup" functions to use context instead of a hard timeout?

[jherman4]

Given that results are streaming to a channel, using a context instead of a hard timeout would be more appropriate. Working with a hard timeout within the concurrency model set up in this library somewhat awkward and limiting. For example what if I want to read entries from a channel until I find all of the entries I am looking for and then move on? Currently to do this you either have to:

1. Choose an overly long timeout and be okay with the goroutine running Query not exiting until potentially long after its task has be fulfilled
2. Repeat calls to Query with a short timeout in a loop

1 means sacrificing performance and even if its unlikely to be a bottleneck in your applications resource use its still pretty grating to anyone who cares about good design. Whereas 2 feels like over-engineering due to utilizing a clunky API.

Having these functions take a context would allow library users to readily choose whether they want to use the timeout model or logic driven cancellation using well defined and understood patterns from the go standard library.

[jwetzell]

I know this issue is old but even the query function that does take a context (QueryContext) is still limited by the timeout part of the params that it takes in. So even if the context passed in isn't done the query client is still closed after params.Timeout has passed.