Context Support?

[dd-caleb]

Was wondering if there was any desire to support context.Context?

I'm working on adding tracing support to some commonly used libraries and Context support is usually a pre-requisite. I thought of a couple ways:

1. The appengine API has:

   func Add(c context.Context, item *Item) error
   func AddMulti(c context.Context, item []*Item) error
   func CompareAndSwap(c context.Context, item *Item) error
   ...

   So maybe there could be a new type of Client with these method signatures instead of the current ones? Something like NewContextualClient(server ... string) *ContextualClient?

2. The github.com/go-redis/redis library has:

   func (c *Client) WithContext(ctx context.Context) *Client

   So you could chain calls like: client.WithContext(ctx).Add(item)

I briefly looked into the second option and I think it could work, but there are a few places where it's not super-clean in order to preserve the existing API (the field names on the Client should probably be in some sort of Pool, and keeping zero-value-struct support is tricky)

If context.Context isn't a great fit for this library, it's probably not essential for tracing because memcache is a terminal span in a trace anyway. I could add the WithContext method to my wrapper and any deadline on the context would just be ignored.

[JensRantil]

I'd vote for not adding tracing support in this package and instead use a wrapper like you propose. However, there might be a benefit in having context support for cancellation of operations (which is something I'm interested in).