a mix-in for easily adding a thread-safe lazily initialized class-level HTTPClient object to your class.
The rdocs say why and how -- if you have more questions about motivations/use cases/why I think this is generally useful, I can explain more.
Feedback welcome. If you aren't interested in having this in HTTPClient, no problem, I'll make my own (tiny, tiny) gem instead. If you are interested, but have some critique, feedback, suggestions, or demands as to implementation, I'm happy to hear em.
a mix-in for easily adding a thread-safe lazily initialized class-level
HTTPClient object to your class.
Hiroshi Nakamura » httpclient #2 SUCCESS
This pull request looks good
Thanks @jrochkind. It looks fine! Before I merge it, can you show me an example that use it? Just a single example would be enough.
There's a 'fake' example in the rdoc. But I am using it in a gem that is under-development, very not mature or not done yet, just beginning, not sure if that's what you're looking for:
Sorry for late reply, and thanks for providing usecase. To be honest I'm still not sure it's the best way to 'extend' a class with module to inherit features but I guess it's enough; you would use it, test exists and it doesn't affect other features. Let me know how it goes with your client.
Yeah, it's totally up to you. Since this additional code is purely additional and doesn't change any existing code, it would be quite easy for me to distribute it as a seperate gem too, then you wouldn't have any implied maintenance responsibility for it. Your call, if you want it or not.
Do you have any suggestions for other ways to easily provide "global persistent" HTTPClient to re-use a client object (and thus re-use persistent connections it's maintaining)?