feat(backend): adding idle and polling mechanism to imap

[Shadow243]

Summary

This PR introduces a backend service that includes:

• Event dispatching system for triggering and handling system-wide events.
• Task scheduling using cron-like jobs with overlapping prevention.
• Real-time notifications via multiple channels (e.g., Telegram, SMS, Slack).
• Ratchet PHP lib integration

Key Features

• Event Class: Implements an event dispatching system where events can be defined and dispatched across the system. This allows for decoupled execution of processes in response to events.

• Scheduler: Manages task scheduling with cron-like expressions, mutex handling to prevent task overlapping, and timezone support.

• Commands: Defines and executes registered commands with dependency injection support.

• Notifications: Notification system with extensible drivers for various channels (e.g., Telegram, SMS, Slack). It allows sending notifications based on event triggers such as new emails.

• Listeners: Allows the system to react to dispatched events by triggering actions such as notifications or logging.

Example Usage Command using database queue driver

Example Usage Command using sqs queue driver

• Related Issue: webhook notification #178
• Related PR: [ENH] Add telegram notification webhook when new messages are detected #1056
• Related RFC: https://datatracker.ietf.org/doc/html/rfc2177
• Related RFC: https://datatracker.ietf.org/doc/html/rfc822

[kroky]

Load the dependencies here and don't include index.php. Treat console as a separate entry point in the application. index.php will be for web requests and this one for cli.

[kroky]

Why do we define another package? It doesn't seem to be runnable without main cypht repo, so better stay as just a subdirecrory in this repo. No need for composer dependencies here.

[kroky]

Please ping me when you add the ratchet lib and polling, so I can review again.

[Shadow243]

Channels tested and fixed

[Shadow243]

schedule:work is also working correctly, i'm receiving Notification every minute as a planned:

[Shadow243]

@kroky Could you review this for me again ? I'm currently working on integrating it with the UI, and the plan is to launch everything through the interface. The Ratchet integration is not implemented yet.

[kroky]

I think we are heading in the right direction but I wonder if we really need all those classes - I see concepts like scheduler, jobs, queue manager, event notifications, etc. - since we are already using symfony components, aren't there libs to use for these implementations? I think we are implementing way too many things currently on ourselves and the code looks similar to other laravel or symfony components. Did you take inspiration from somewhere? If so, can't we use those libs as they will be better maintained and tested if we do so?
Also, there is no need to prefix everything with Hm_ in services - it is a new module and can be named normally.

[marclaporte]

I see concepts like scheduler, jobs, queue manager, event notifications, etc.

FYI, this is coming soon: https://gitlab.com/tikiwiki/tiki/-/merge_requests/5453/

[kroky]

After a discussion with @Shadow243 about the reasoning behind the manual implementation of the new concepts, we decided to go ahead with this approach rather than introducing a ton of external dependencies which would require even more 3rd party libs. Some considerations from the discussion with Steven:

1. Existing Libraries: While there are Symfony and Laravel libraries for schedulers, jobs, queues, etc., many come with a lot of dependencies we don’t need. For example, Laravel’s illuminate/queue pulls in things like illuminate/database, illuminate/support, and ramsey/uuid, etc..., which can bloat the project unnecessarily.

2. ORM Compatibility: Since we are using Cypht without an ORM, libraries requiring Doctrine(ex: symfony/messenger) won’t integrate cleanly and could add unnecessary complexity.

3. Custom Implementations: Yes, our code resembles parts of Laravel and Symfony components because we’ve taken inspiration from established patterns. However, the custom implementations are tailored specifically to our needs, keeping things lightweight and avoiding dependencies we won’t use.

4. Package Maintenance: Many libraries we researched were abandoned or didn’t fit our ecosystem. Laravel’s ecosystem is advanced, but it often forces you to pull in extra packages that aren’t relevant to our use case.

5. Symfony Messenger and Event Dispatcher: I could combine symfony/messenger with symfony/event-dispatcher, symfony/contracts, and symfony/dependency-injection to manage these functionalities. However, I’d face a challenge with queueing since Symfony doesn’t have a dedicated queue component without internal depandacies(like ORM, etc...).

This approach ensures flexibility without overloading the project. If you know of lightweight, actively maintained libraries that fit our needs, let me know, and we can evaluate them.

Most Important: Features like the scheduler, events, listeners, and queues are highly advanced in Symfony, just like in Laravel, and have interdependencies that could pose problems. Cypht, on the other hand, intentionally remains simple (no ORM, etc.), while Laravel and Symfony rely on more complex components to manage a large part of their functionalities.

E.g: composer require illuminate/queue requires

php: ^8.2
illuminate/collections: ^11.0
illuminate/console: ^11.0
illuminate/container: ^11.0
illuminate/contracts: ^11.0
illuminate/database: ^11.0
illuminate/filesystem: ^11.0
illuminate/pipeline: ^11.0
illuminate/support: ^11.0
laravel/serializable-closure: ^1.3|^2.0
ramsey/uuid: ^4.7
symfony/process: ^7.0.3

[marclaporte]

Please keep this list alphabetically sorted.