Refactor Telegram.php

[noplanman]

This issue is intended as a discussion board and checklist of tasks to refactor the Telegram class.
(new class names are just suggestions and prone to change)

The main objective is to separate the responsibility and to decouple as much as possible.
The Telegram class should handle only the main Telegram API related functionality and thread all sub-processes together by saving necessary objects in member variables, making them available to modify certain features. (i.e. having a $commander variable that handles all "command" functionality, etc.)

• Extract all command related functionality to a dedicated Commander class.
• Extract all logging related functionality to a dedicated Logger class.

[MBoretto]

It would be nice to separate also the log part.
Here's some thougts about:

• Logging should handle Request log as incoming update and also exception log in order to fix The path used for writing to TelegramException.log is a security risk #96
• Since some months at every version the table schema change. Sorry for this.. No one complain about this but is a pain move existing data from a schema to another. In order to overcome this problem I was thinking that the incoming log update can be used to refill the database when the schema change. What you think about this?
• For debugging purpose was useful to me to have a single log file where i can see both incoming update and curl response of the library (according to log level). This feature is not good if we want to implement database refilling. We should find a way to handle those things together (If we decide to develop both)

[noplanman]

How exactly do you envision the database refilling?
I don't understand how it's connected to the logging 😕
Please do explain more 😃

Have you thought of having a dedicated upgrade file that can be executed to update the database structure? Then, each time the schema is updated, the user can just run the "update" script and all the changes are made automatically. All we need to do then, is have a way to remember which database version we're on, so that only the new changes are applied.

[MBoretto]

Incoming update (json string from webhook and getUpdates) can be logged in a text file with those options with the methods:

$telegram->setLogRequests(true);
$telegram->setLogPath($BOT_NAME . '.log');

So if you store all the incoming update in a textfile you can build a mechanims than read them all and reprocess it without send request back. In this way you can refill database.

[noplanman]

Aaaaah, now I understand what you mean!

So basically what you're saying, is to save all updates to a separate file, which can be used as a data import on the database?

Is this necessary? Wouldn't it be enough to just track the database schema changes and update the database after each new version?
For an active bot, the import log file could become really big and the use can disable it, which brings us to the same problem 😕

[MBoretto]

In the very beginning, there was just a table that stores everything.

• Chat and user object were stored as json string in a table column..
• During develop lot of bugs came out, sometimes i found that data of updates were not stored properly in the table

Row json log are the only one that contain the 'truth'.
Can be a form of 'retrocompatibily' for table schema changes, and database leakage if any.
Maybe is not a priority but we cant take this in mind.

[BoShurik]

In case of logging, maybe rely on standard LoggerInterface
and suggest through composer, for example, monolog

[noplanman]

@BoShurik Already planned, as you can see here: #167