Please don't let context pollute the apis

[elgs]

I switched from go-redis because their apis are heavily polluted by the context. I come here to beg you please please don't pollute your apis with the context virus.

[stevenh]

Hi @elgs I don't see us removing the none context functionality, but to ensure I understand your need could you clarify your objections to context?

[elgs]

@stevenh thank you for allowing your clients to not get involved in the context and still to get things done.

I am not objecting context per se. The idea of context itself is nothing wrong. Since the http server is the first class citizen in Go, I understand context was built in the language by some opinionated people. That's ok. Context is no more than notifying some channels when things get canceled or timed out. In my opinion these are implementation details and are easy to be done in other/simpler ways. So I don't see why they need to be exposed to the api if it's not absolutely necessary. Also I don't believe context is the only most elegant way to achieve handling canceling and timeout. I have no problem anyone uses it for their implementation, but it's unnecessary to force the client to get involved, especially when they don't necessarily need it.

[stevenh]

Thanks for the context @elgs.

I would say that the consistency that context brings with handling timeout and cancellation is quite a benefit.

It's all to common for API's to ignore the edge cases which are often inherited from the underlying transports such as TCP, which can result in some serious challenges when those rare cases occur, for example if keep-alive isn't enabled broken connections go unnoticed creating hard to detect resource leaks.

Context not only provides a consistent way of handling that, it does so in a way that makes the developer think about some of these edge cases.

Hopefully that provides some food for thought.