You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Concurrency has been popular for IO heavy applications like EFB. There’s a wide range of frameworks like aiorequests / telethon / fbchat-async that has first-class AsyncIO support. We might need to redesign our framework to adopt that.
Describe the solution you'd like
Need sometime to think of a redesign of the framework, especially the communication part, to adopt AsyncIO.
Currently the most popular slave channel, EWS, is depending on unmaintained-for-years libraries (namely itchat and wxpy) that has been forked and vendored into EWS. We might need to rewrite them to fit the AsyncIO pattern. Or consider using libraries like trio to wrap around them.
Describe alternatives you've considered
N/A
Additional context
As always if you have any suggestions on how we shall design the framework or so, leave a comment below.
The text was updated successfully, but these errors were encountered:
Hi, @blueset. Actually, I am interesting in this problem. And I want to ask you some questions.
Now the EFB framework initializes the Thread for one master channel and many slave channels. And all the channels define start_poll method to start their own functionality. And If we want to use asyncio library, why not just change the Threads to Coroutines. I know it won't such simple, so I am confused about the needs.
How the concurrent should be? Channel-to-Channel level or something else?
For a better way, we shouldn't change the API provided, but could it be realistic?
Is your feature request related to a problem? Please describe.
Concurrency has been popular for IO heavy applications like EFB. There’s a wide range of frameworks like
aiorequests
/telethon
/fbchat-async
that has first-class AsyncIO support. We might need to redesign our framework to adopt that.Describe the solution you'd like
Need sometime to think of a redesign of the framework, especially the communication part, to adopt AsyncIO.
Currently the most popular slave channel, EWS, is depending on unmaintained-for-years libraries (namely
itchat
andwxpy
) that has been forked and vendored into EWS. We might need to rewrite them to fit the AsyncIO pattern. Or consider using libraries liketrio
to wrap around them.Describe alternatives you've considered
N/A
Additional context
As always if you have any suggestions on how we shall design the framework or so, leave a comment below.
The text was updated successfully, but these errors were encountered: