Add context.Context support

[derekperkins]

For all the network calls made in this package, it would be nice to be able to use context.Context as the first parameter to all the calls, allowing for program control over cancelation deadlines, metrics and all the other good things that come along with it.

[brandur]

That would be cool.

Unfortunately, I think you'd want to be able to supply a Context as a parameter for every single HTTP call currently in the library, which would necessitate some pretty heavy refactoring here.

Tagging this as "future" for now.

[pjebs]

Also bear in mind that Google App Engine users still only have access to: golang.org/x/net/context AND NOT context.Context since GAE runtime is still officially using Go1.6

[derekperkins]

@pjebs That's only for the next few weeks until GAE adds support for 1.8.

[klauspost]

Without knowing the details, I could see this fairly simple implementation:

First of all, add it to the common parameters:

// Params is the structure that contains the common properties
// of any *Params structure.
type Params struct {
	// Context used for request.
	Context context.Context `form:"-"`

Package users then simply adds the context to the parameters they send.

To add it to all requests is then simply a matter of adding it to the Call interface of the Backend:

	req, err := s.NewRequest(method, path, key, "application/x-www-form-urlencoded", body, params)
	if err != nil {
		return err
	}
	if params.Context != nil {
		req = req.WithContext(params.Context)
	}

	if err := s.Do(req, v); err != nil {
		return err
	}

• similar thing in CallMultipart.

AFAICT this is backwards compatible and allows sending a custom context to each request. It requires Go 1.8 of course.

It is not idiomatic, but it doesn't require you to have all calls duplicated like client.NewContext(ctx context.Conrext, params *stripe.SKUParams) (*stripe.SKU, error), etc.

[brandur-stripe]

Good point Klaus! I've added an implementation based on your suggestion in #477. Thanks.

AFAICT this is backwards compatible and allows sending a custom context to each request. It requires Go 1.8 of course.

Good news on that front even! Context came in as part of 1.7, so all the version of Go in our matrix can support the change.

[brandur-stripe]

And actually, if anyone on here would be willing to take a quick look at #477 just to see what they think from an API perspective, it'd be greatly appreciated. I'll hold merging it a few days to see if we can gather a little feedback.

[jmhodges]

An alternative is to work like database/sql and add Context versions of the methods under a different (but similar) name. That style seems to be more common (and avoids the "don't put Contexts in structs" review comments).

[klauspost]

like database/sql

Yeah, but that would require duplicating all methods on all clients and also do it for the "client-less" functions in each package. A rough estimate is 280 duplicated functions.

A func (p *Params) WithContext(c context.Context) *Params could be added that returns a shallow copy with a context similar to (http.Request).WithContext. I still think the context should be exported since I suspect a lot of parameters are created just before they are sent.

[brandur-stripe]

Thanks for your patience everyone! We've released basic support for Context in 28.4.0.