[Discussion] Redesign some core components

[Chase22]

After taking a look at Issue #914 i also looked into the DefaultBotSession as it is and while the implementation works as is i want to open the discussion if it is time to rewrite and redesign those core components looking at new features and best practices of Java 8 to Java 11. Some of the line in there date back almost a decade.

Some points i'd like open up:

• Redesigning the Threads, maybe split up the implementation
• Offer a way to supply own implementations for those threads easily (Inject a thread factory?)
• Use Executors and threadpools to create the threads
• Maybe implement a way for all updates being handeled in individual threads

I'd like to hear opinions of other devs and espacially @rubenlagus on this.

[rubenlagus]

@Chase22 Happy to redesign part of those core componenes, as long as we keep the functionality of them:

• Only one consumer thread from Telegram server
• No breaking changes or if so, keep old version available
• Updates must be processed in order

I agree that this code is quite old and not best designed, tbh, this part was built back them with the initial version of the API when I wasn't expected it to grow that much

[Chase22]

I'm picking this up again. My propsal would be to split the Library into three distinct parts:

Update Supplier <- The stuff that gets updates from somewhere. For example via Longpolling or Webhook

Business Logic <- Mostly supplied by the user. Currently would be the Implementation of TelegramBot

Telegram Executor <- The stuff that sends Requests to Telegram

These parts can be replaced and plugged together dynamically, The library would supply interfaces for the Supplier and Executor and also Supply default implementations. The user can easily replace any part of this chain for example for testing or because they have some special needs for the library.

One use case could for example be replacing the Update Supplier with a Spring Controller that implements a webhook using the Spring-Web Framework.

I will be working on a Proof of Concept and send that in here when it's done

[Chase22]

I made some progress on planning and basic implementation. The concept changed a bit, here are the components:

The entire library will be build as a chain of responsibility. The chain start is the update coming from telegram and the chain end is the method send back to telegram. This modular approach allows people to build bots that don't react to updates by interacting with telegram or bots that will only ever send messages, but never receive them, without too much overhead.

Update Supplier: Still remains the components that receives Updates one way or another.

Update Distributor: This is responsible for distributing updates to different parts of the bot. For example Multithreading can be implemented here. It's also possible to have consumer for different Update Types.

Update Consumer: Any Logic that consumes an update. This is the main part the user will be working on. It is possible to have multiple update consumers running at the same time

Telegram Executor: The actual client part, this executes all methods towards telegram.

For basic usage there is a wrapper class that will just have the known execute() and onUpdateReceived() methods and wraps all of the logic underneath. For advanced users it's recommended to initialize the components individually and plug them together.

The best migration plan imo is to keep the entire existing infrastructure as is and make it deprecated. There are drop in replacements for the Telegrambots and with the next major version most of the old bot infrastructure can be remove.

The current progress can be seen here. A lot is still up for changes
https://github.com/Chase22/TelegramBots/tree/rewrite

[rubenlagus]

@Chase22 Probably we can take this chance to remove the HttpClient from Oracle and move into the standard one from Java 11

[rubenlagus]

@Chase22 Was thinking about this redisign and I'd be up to split the library in 4 base modules/jars:

• telegrambots-meta: as it is now (probably some things being removed)
• telegrambots-shared: A base liine containing shared component between webhook and long polling technology (if required)
• telegrambots-webhook: Webhook required components
• telegrambots-longpolling: LongPolling required components

Comments?

[Chase22]

What i would split it up into is

meta: Only the Telegram API bingings. As little logic as possible
executor: The part that interacts with the telegram api by sending methods
longpolling and webhook: as described above

I don't think there will be a lot of shared code between the two.

I'm not sure if it makes a lot of sense to split up longpolling and webhook. The actual implementation of the two will be quite small, but i'm fine with it

[rubenlagus]

My idea is that users can choose to implement their own versions of the longpolling/webhook if they want while getting most of the logic to send messages out of the box from the telegrambots-shared package.

For example, to use spring, most of the times, spring will be used to generate the restful API so it is not necessary to have the default implementation.

[Chase22]

I understand. I would consider naming it something other than "shared" since it is a useful package on its own, both for people making their own implementation and for people that don't need to receive messages

[rubenlagus]

Agree, it can be named something like telegrambots-base or similar.

I'll try to create a branch with the initial idea (naming can be decided later)