Improve UpdateManager flexibility

[HedgehogNSK]

I’ve been working on implementing webhooks for a few days. As far as I know, the library currently doesn’t provide built-in support for working with webhooks directly. To address this, I’ve been using another open-source library that provides an HTTP server. With this setup, I can now deserialize webhook data into an RxTelegram.Bot.Interface.Setup.Update object, which is already part of this library. I noticed that the internal processes of the UpdateManager class utilize Update objects as well, processing them through the DistributeUpdates method. I would like to have the ability to process Update objects received externally in the same way, by passing them through DistributeUpdates.

This method appears to be flexible enough to handle updates from any provider, whether it’s long-polling, webhooks, or other custom sources. This observation led me to consider potential improvements to the UpdateManager design. Right now, the UpdateManager.RunUpdate method acts as a standalone service, specifically designed for long-polling requests.

To make the system more modular and extensible, I propose splitting the UpdateManager into two separate components: UpdateDistributor and IUpdateTracker.

• The UpdateDistributor would handle the distribution of raw Update objects from the IUpdateTracker.
• The IUpdateTracker would be responsible for tracking and retrieving updates, allowing for multiple implementations. [edited: I just finished draft version of Webhook tracker and it looks more natural to use IObservable<Update> for tracker]

By default, the UpdateManager could use a long-polling update tracker, but this design would also support additional trackers, such as a webhook update tracker or even a custom test update tracker that developers could implement themselves.

This design would make it easier to extend and maintain the library, providing a cleaner separation of responsibilities. It would also allow developers to integrate webhooks or other custom update sources seamlessly while still leveraging the existing UpdateManager functionality.

P.S. I'm planning to modify the current UpdateManager to handle Update objects received via webhook. Once I’m done, I’d be happy to share the changes with you, if you're interested.

[HedgehogNSK]

Well, I've finished the splitting. :)

I've successfully divided the UpdateManager into UpdateDistributor and LongpollingUpdateTracker.
LongpollingUpdateTracker implements IObservable<Update>. UpdateDistributor accepts IObservable<Update> objects and implements the IUpdateManager interface . This makes it much easier to implement custom update trackers. I also extended the IUpdateManager interface with the Set(IObservable<Update>) method. So it's possible to switch from long polling to webhook on the fly. I've already tested in my app this function.
In the next few days, I will clean up my code, and I'm also considering extending UpdateDistributor to allow users to set multiple trackers at once.

I’ve pushed a commit to a forked repository to give you access to assess the changes I’ve made so far... If this is of interest to you, of course.

[niklasweimann]

This looks interesting to me. If you would like to have this in RxTelegram please feel free to create a pull request. ;)

[HedgehogNSK]

Thanks. I'm glad to hear this. :)

Should I create a PR as it is? I’m asking because I extended IUpdateManager with a Set method, but I didn’t implement it in the current UpdateManager since it’s no longer being used.

public class UpdateManager : IUpdateManager
{
    public void Set(IObservable<Update> tracker) => throw new NotImplementedException();
...

[niklasweimann]

Yes, you can create the PR. I would not like to have the NotImplementedException in the final version, but I am sure we can finish the implementation in a brach first and than merge it into the main branch.

[HedgehogNSK]

Actually, the UpdateManager can be removed because the UpdateDistributor and LongpollingUpdateTracker are the results of the UpdateManager being split. :) Since it was an encapsulated field of the TelegramBot and users accessed it via the IUpdateManager interface, there should be no issues with backward compatibility.

P.S. I created the PR.