Server-sent events handler

Bonjour à tous !

Je viens vers vous aujourd'hui pour quelques questions par rapport à Monolog et à la possibilité d'intégrer des SSE.

Le souci que je rencontre, c'est que je ne vois pas trop comment je peux envoyer des données tout en répondant à un URL spécifique depuis un handler. J'ai l'impression que les données seront des objets Response, donc j'imagine que je devrai implémenter d'autres interfaces ou étendre une autre classe que pour un handler "classique", mais je ne vois pas trop bien le(s)quelle(s), même si je pense qu'une classe Controller pourrait être intéressante à étendre.

Je lis déjà ceux qui vont me dire d'utiliser les WebSockets, mais ça me paraît un peu overkill pour, au final, simplement envoyer des notifications depuis le serveur, surtout qu'il n'y aura aucune interaction. L'idée première est vraiment d'envoyer les logs au format SSE.

Est-ce que quelqu'un qui connaît un peu mieux les truchements internes de Symfony aurait quelque chose à me proposer ?

Merci 

OK, je vais temporairement faire avec un SocketHandler.

Je reste néanmoins à l'affût pour une solution par "pur HTTP"

De mémoire HTTP est plutôt fait pour fonctionner du client vers le serveur (requête → réponse).

Peut-être qu'avec HTTP/2 tu pourrais forcer quelque chose mais ça me paraît plus être de la bricole qu'autre chose (surtout que ça se fait pendant la réponse du serveur donc sur un temps limité).

Après les sockets avec PHP ça m'a toujours semblé un gros bordel pour rien, surtout que c'est pas un langage très adapté (ça fonctionne surtout pour répondre à des requêtes, pas comme un serveur indépendant, comme Node.JS le ferait) à la base

Dommage…

J'avais naïvement pensé, en voyant l'exemple donné sur la page MDN des Server-Sent Events que ç'aurait été possible… La seule pièce qu'il me semblait me manquer, c'était comment rediriger le flux vers un URL plutôt que vers un fichier/boîte mail/etc., ce que Monolog permet déjà de faire.

Ah oui, ils laissent tourner une boucle en fond. C'est plutôt dangereux, non ?

Sur une poignées de clients ça posera pas trop de problèmes, mais très vite tu auras des centaines de processus qui moulinent en fond, ça me paraît beaucoup pour le serveur…

Je le pense aussi…
En fait, de ce que j'ai pu comprendre, c'est soit une tâche qui tourne en fond et la connexion est persistante, soit de multiples et régulières connexions (par défaut, c'est toutes les 3 secondes, mais on peut paramétrer ça dans le flux avec retry: [nombre de milisecondes avant reconnexion])

Mais ça pose un problème de buffer quelconque à vider, du coup. Et comme il y aura probablement plusieurs abonnés, à moins que je multiplie les canaux, un par abonné…

Edit

Je vais mettre quelques pistes intéressantes ici.

• Server-sent events and php - what triggers events on the server?
  Intéressant de se dire que stocker dans une base de données et envoyer sur demande pourrait déjà être une piste intéressante…
• Stream Updates with Server-Sent Events
  Tiens, il utilise ceci :
  • Chunked transfer encoding [fr]

C'est typiquement dans ce genre de cas qu'on atteint les limites de PHP je trouve.

Il faudrait un moyen de faire tourner un script en fond, façon Node.JS, qui agirait comme serveur (et pourrait donc gérer un tas de protocoles). Mais du coup ça voudrait dire remplacer Apache/nginx.