cache replyto chat #69
Conversation
so no need to replyto every msg
|
Hi, can you further elaborate on what this PR changes? It'd be great if you can update the README file if this PR involves changes in user interaction. Thanks! |
|
usually, we need to reply to a message in a private or group with multi
slaves.
so the etm can know where to send.
this pr cache the destination when you reply to a message. then, if you
send a message without replied infomation, it will use the last cached
destination.
|
|
Thanks for the explanation. Several other users has also been suggesting similar features trying to avoid quote reply when sending messages to non-linked or multi-linked chats. However, I always have this concern where this kind of logic could lead to unintended behavior, especially when a lot messages has been received between two of such messages sent to Telegram. For example, with the logic you have suggested: After a longer period of time, the user might just forget who they last replied. And when they got a long chunk of messages from another chat, they could either simply assume the next message they sent would be to that new chat, or they could simply forget to do the "quote-reply" action. In either case, the new message would be delivered to unintended recipient and cause unnecessary problem once sent. Furthermore, ETM's default behavior doesn't include a delivery receipt for most messages (including the new message mentioned above). The user wouldn't event notice that the message is sent to the wrong chat. Some other users have suggested that messages with no indicated recipient should be sent to the chat where last message in that Telegram thread is from. This would also prone to misdelivery where messages from multiple chats are coming continuously to this Telegram thread. See the char below for details. Sequence chartIf you have better suggestions or further question on this problem, feel free to leave a comment below, or better if you would have another PR. |
|
At the beginning, I had thought about this question. |
|
Agree with @blueset . I don't think it's a good idea to cache replyto chat, at least not in a way with no explicit notification about which chat the user is replying to. Actually, I think the approach proposed by @wolfsilver that expires a cache after a short period of time, 'cauze it may make user even more confusing. I think we should keep the status consistent without user's operation. If we really need this feature to reply to a chat instantly with no need to create a new group to link to, maybe we need a new commands to check the chat that the user want to reply to. In this case, we could cache the last replied chat as this pr does, and users could check the chat they are to reply by typing something like
|
|
Even with a check command like If we would take the timeout version of the "cached reply-to" strategy proposed here by @wolfsilver, it's probably better to notify the user about what ETM is going to do on this chat every time it starts to use/change the cache, like:
However, I would still consider this as an arguable feature, and would prioritize more on other existing proposals, unit tests and stable version releases. As usual, if there are better implementations, I'll be more than grateful to give the PR a review. |
|
How about this. cache expired after an hour. The original intention of this pr is to solve the temporary chat group that maybe not used after hours or one day. It's not for long term situations. |
|
This looks like a better strategy so far. Does your current code work like that? |
|
Yes.
It worked fine for me.
Maybe using a configuration to set the expire time is better way.
Eana Hufwe <notifications@github.com> 于2019年9月14日周六 下午12:23写道：
… This looks like a better strategy so far. Does your current code work like
that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASWXYR6R4QQ7E73S2V34KTQJRRMNANCNFSM4ISOUHNQ>
.
|
There was a problem hiding this comment.
👍 Brilliant work in general! 🎉
I've left some comments in the code. Please take a look and see if you have any doubt or question on them.
Also, I happened to encounter some similar code online while searching for the meaning of some comments in code. In case that you have taken any code from other sources, please take care if that is fine copyright-wise. Don't forget to attribute the original author and/or license if required.
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
Co-Authored-By: Eana Hufwe <ilove@1a23.com>
|
I have no better practice. So I just take all your advice except #69 (comment) |
|
Thanks for the effort! I'll merge this now. |
* cache replyto chat so no need to replyto every msg * Mod modify cache replied chat logic * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/slave_message.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * Update efb_telegram_master/cache.py Co-Authored-By: Eana Hufwe <ilove@1a23.com> * fix code review problem
so no need to replyto every msg