Skip to content
This repository has been archived by the owner on Nov 5, 2019. It is now read-only.

Plan to Implement: oauth2client.transport module #554

Closed
dhermes opened this issue Jul 19, 2016 · 7 comments
Closed

Plan to Implement: oauth2client.transport module #554

dhermes opened this issue Jul 19, 2016 · 7 comments
Assignees
Labels
Milestone

Comments

@dhermes
Copy link
Contributor

dhermes commented Jul 19, 2016

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.

@nathanielmanistaatgoogle
Copy link
Contributor

No concerns. I think I've heard rumblings about this for a while.

dhermes added a commit to dhermes/oauth2client that referenced this issue Jul 20, 2016
dhermes added a commit to dhermes/oauth2client that referenced this issue Jul 20, 2016
dhermes added a commit to dhermes/oauth2client that referenced this issue Jul 21, 2016
dhermes added a commit to dhermes/oauth2client that referenced this issue Jul 21, 2016
dhermes added a commit to dhermes/oauth2client that referenced this issue Jul 21, 2016
@theacodes theacodes modified the milestone: 4.0.0 Jul 27, 2016
@txomon
Copy link

txomon commented Jul 29, 2016

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.

@theacodes
Copy link
Contributor

@txomon I'm not sure about async transports, but this will certainly make something like that a lot more feasible in the future.

@txomon
Copy link

txomon commented Jul 29, 2016

Some difficulties I have found until now is that the docs say that
implementing request function is enough but doesn't give a signature nor
clear signature.

Making that a little more flexible is highly appreciated =) Thanks!

On Fri, 29 Jul 2016 18:25 Jon Wayne Parrott, [email protected]
wrote:

@txomon https://github.com/txomon I'm not sure about async transports,
but this will certainly make something like that a lot more feasible in the
future.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#554 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN7mgAroLoSldVTjlGTKtjD5Py7Y9bgks5qaimGgaJpZM4JQDbU
.

@theacodes
Copy link
Contributor

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.

@dhermes
Copy link
Contributor Author

dhermes commented Jul 29, 2016

@txomon There are a few more details in #128. The goal is to define an interface that a BYO transport implementation needs to comply with and then just support that. We'll probably have to support the BYO stuff side-by-side with the default httplib2 stuff for a generation or two.

@dhermes
Copy link
Contributor Author

dhermes commented Aug 1, 2016

Calling this complete and moving discussion back to #128

@dhermes dhermes closed this as completed Aug 1, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants