Skip to content
This repository has been archived by the owner on Mar 9, 2024. It is now read-only.

[enhancment] asyncio support could be useful #50

Open
moneroexamples opened this issue Apr 26, 2019 · 6 comments
Open

[enhancment] asyncio support could be useful #50

moneroexamples opened this issue Apr 26, 2019 · 6 comments

Comments

@moneroexamples
Copy link
Contributor

asyncio support could be a nice enhancement of the project. For now the project uses requests to interact with monero wallet and daemon through rpc in a blocking fashion.

Thus a possible improvement could be to support aiohttp and asyncio for asynchronous programming.

@emesik
Copy link
Contributor

emesik commented Apr 26, 2019

Great idea! Non-blocking API would be great for many applications. However, I have no experience with that in Python. If you think you could start it, please go ahead.

@moneroexamples
Copy link
Contributor Author

Unfortunately, I will not have time to work on that in near future, as all my time goes to moneroexamples projects at present. But it could be good exercise and learning experience for anyone interested in modern python developments.

@lalanza808
Copy link
Contributor

I have done some projects using the aiohttp library. I can look into this more, but also make no promises as life usually gets in the way of my nerd hobbies :)

@lalanza808
Copy link
Contributor

Doesn't look like aiohttp supports digest authentication out of the box, only basic auth. There's a 2 year PR sitting on the project for it though: aio-libs/aiohttp#2213

I believe the JSON RPC interfaces only accept digest auth, plus it would be preferred over plain text basic auth anyways. I'll look around for some other viable libraries that make use of non-blocking HTTP calls that support digest auth. The project only makes use of HTTP calls in one single file so implementing won't be too difficult, will probably spend more time refactoring tests :)

@lalanza808
Copy link
Contributor

I don't know that I can make it asynchronous and still work with Python 2 unless we want to fork the logic and write it twice. Should we rip off the band-aid?

@emesik
Copy link
Contributor

emesik commented Aug 13, 2019

Py2 is going away next year, so I guess we shouldn't worry about backward incompatible changes. I can manage backporting other features for some time, as the project isn't very busy.

Let's do it on a separate branch, though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants