-
Notifications
You must be signed in to change notification settings - Fork 431
Plan to Implement: oauth2client.transport module #554
Comments
No concerns. I think I've heard rumblings about this for a while. |
Does this mean we will be able to use our own http clients? I am mostly interested on using aiohttp to do async requests. This sounds like having the functionality of the oauth2 steps separated from the implementation of the transport, but I don't know if it supports the use case I just mentioned. |
@txomon I'm not sure about async transports, but this will certainly make something like that a lot more feasible in the future. |
Some difficulties I have found until now is that the docs say that Making that a little more flexible is highly appreciated =) Thanks! On Fri, 29 Jul 2016 18:25 Jon Wayne Parrott, [email protected]
|
That's the goal. Ultimately we want to support urllib3/requests as the primary transport and deprecate httplib2. To do that, we more or less have to enable users to bring their own http client. Two birds, one stone. |
Calling this complete and moving discussion back to #128 |
FYI @nathanielmanistaatgoogle @jonparrott @waprin I am going to factor out all of the usage of
httplib2
into a standalone module so we can have a clean break when the time comes to use a better maintained library.I plan to start soon to please weigh in ASAP with any comments or concerns or requests for API surface area.
Also see #128 for a more "detailed" (but old) plan.
The text was updated successfully, but these errors were encountered: