Comments (5)
I think what @HKalbasi is trying to highlight here is that dialogues are usually short lived, so in a lot of cases it does not matter much if we lose it. (the probability to loose it mid dialogue is lower because it's short lived, it can be redone easily for the same reason, etc)
from teloxide.
And it doesn't need to replace the current api, just complement it. For long dialogues or cases that persistence is very important, users can always use the current api.
from teloxide.
I think what @HKalbasi is trying to highlight here is that dialogues are usually short lived, so in a lot of cases it does not matter much if we lose it. (the probability to loose it mid dialogue is lower because it's short lived, it can be redone easily for the same reason, etc)
A sudden interruption of the control flow can still look like a bug though. If a bot has enough users, this will certainly be noticed at some point.
My other concern is having two alternative implementations of the same idea. What usually happens is that users prefer the nicer-looking solution, then (some part of users) stumble upon the limitations of the basic solution, then rewrite the logic to use the more advanced solution. We already have it in the form of REPLs/dispatcher. Having it also for dialogues/.await
points means that once a user of the library decides to use state machines instead of .await
, they will need to rewrite almost the whole bot logic (in addition to breaking library changes). Having FSM-based logic right from the beginning would thus save time long-term.
Other than that, I agree with @WaffleLapkin that we don't have the capacity to implement it anytime soon.
from teloxide.
In this way we store the state in the tokio task local variables, so we will lose it on bot restart. This tolerable in most cases, and sometimes even desired. We can always manually store things in the persistent storage in important checkpoints, and use this api for short dialogs.
Consider what happens when a bot gets restarted, which can happen due to some server error or if you decided to update the code. In this case, a user should not notice anything, but with the approach you've suggested the dialogue will be removed from memory and lost forever. From the point of a user, it'd look like a bug.
It's true that .await
is much more readable and declarative though. In essence, .await
can be described as a finite state machine (I remember there even was a macro for that back in the old days). However, I wasn't able to figure out how to exploit .await
to make it compatible with persistent dialogues.
Also, the approach of saving the dialogue state in certain points is error-prone -- we can just forget to do that. On the other hand, the current approach with FSMs does it automatically behind the scenes.
from teloxide.
I think my biggest concern here is that this requires quite a bit of design & implementation work. Given our capacity I don't think we'll be able to get to it anytime soon.
But it does look like with enough work & workarounds, this should be possible to implement. So, maybe one day :)
from teloxide.
Related Issues (20)
- High CPU usage when internet is unavailable HOT 2
- Feature Request: make error_handler in Dispatcher able to accept deps HOT 1
- It seems like `Update::filter_pre_checkout_query` does not catch pre_checkout_query HOT 3
- Potential refactor ideas for requests HOT 3
- Dependencies shared by teloxide and teloxide-core have disparate versions HOT 2
- Feature Request: Option to suppress timeout errors HOT 1
- An error from the update listener: Api(TerminatedByOtherGetUpdates) HOT 5
- Feature Request: add `forwardMessages`, `copyMessages`, `deleteMessages` and `getUserChatBoosts` HOT 1
- BotCommands can't derive enum variant where field is a custom struct
- unpin_chat_message missing message_id optional parameter HOT 2
- Feature Request: Upgrade reqwest crate HOT 1
- Feature Request: Add support for Bot API 6.6
- Parse Error: Data did not match any variant of untagged enum TelegramResponse for `getStickerSet` HOT 7
- Incorrect parsing `InlineQueryResult` variants HOT 5
- Bot stops responding after some time: Only to commands in group chats it seems HOT 10
- Not all update kinds implement `GetChatId`
- PollAnswer not handled by the dispatcher HOT 4
- Feature Request: explicit and intuitive `SendMediaGroup` caption support HOT 5
- Incorrect type of `audio_duration` in `InlineQueryResultAudio` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from teloxide.