Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a per-chat message queue or similar for incoming messages #88

Open
blueset opened this issue Dec 15, 2019 · 7 comments
Open

Comments

@blueset
Copy link
Member

blueset commented Dec 15, 2019

Currently (since 2.0.0b26), ETM is using a single message worker thread to process all incoming messages from the Bot admin in order to maintain a proper message order, and processing messages from slave channels on a per-call basis sent to Telegram.

While this former measure does help bring a proper message order, this is blocking all incoming messages in all chats when the worker is trying to process large (usually media) messages. This is obviously a behavior that we don‘t want to have in ETM. The latter is seemingly is not blocking, but this could result in a out-of-order message thread when a specific message needs to take more time than others.

I‘d like to look for help/suggestions to solve this problem by maintain a per-chat message order consistency while prevent blocking as far as possible. That could be a per-chat message queue or anything that could serve the same purpose.

@blueset
Copy link
Member Author

blueset commented Dec 16, 2019

For messages from slave channels, @catbaron0 and @wolfsilver has suggested to use a placeholder first create a message at the “correct position”, then process and upload the actual media.

This is a viable solution to this problem as it works with majority ETM-supported messages types, and seemingly reduces the first request (the placeholder request) to a single simple request. Telegram Bot API (and user API) allows sending media with resources pre-exist on its server, and modifying message media to one of animation, document, audio, photo, video.

To implement this feature, we need to send the placeholder message (preferably a picture) once per bot, and store the file ID somewhere (potentially in the database).

On the other hand, this method does not support some message types frequently used by ETM, namely stickers and voice messages, which means these messages could still be out of order.

If there is no better solution found for this issue, I‘d recon that this shall be implemented as a partial solution to this problem after ETM has a stable version released (i.e. when ETM has a acceptable amount of tests available).

And as always, PRs are welcomed.

@catbaron0
Copy link

send the placeholder message (preferably a picture) once per bot

Would it be better (or possible) to send an empty(0 kb) file as the placeholder?

@wolfsilver
Copy link
Contributor

send the placeholder message (preferably a picture) once per bot

Would it be better (or possible) to send an empty(0 kb) file as the placeholder?

I think if show a picture like this would be better.

image

@blueset
Copy link
Member Author

blueset commented Dec 16, 2019

send the placeholder message (preferably a picture) once per bot

Would it be better (or possible) to send an empty(0 kb) file as the placeholder?

Telegram (both user API and bot API) rejects empty file to be sent. Even if it’s possible, that might not be as visually appealing and straight forward than a picture.

@blueset
Copy link
Member Author

blueset commented Dec 16, 2019

As for the picture, I’d personally prefer something language-neutral, since translating image resources could be kinda painful sometimes.

And this is a prototype I made just now:
etm-loading-card

... and how it looks like on Telegram:

image
image

@catbaron0
Copy link

Cool.
But still I prefer some description of the file type in the text field.

@blueset
Copy link
Member Author

blueset commented Dec 16, 2019

Cool.
But still I prefer some description of the file type in the text field.

That could be done in the caption.

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

No branches or pull requests

3 participants