Faraday: Liste des fonctionnalités pour les prochaines grandes versions

Je cherche du support pour le streaming... est-ce que quelqu'un travaille sur la 1.0 ? ... sinon pourquoi l'autre PR a été fermé 😕

Salut @grosser , les raisons sont exprimées dans ce https://github.com/lostisland/faraday/pull/604#issuecomment -259125910.
La raison principale était que le PR n'était compatible qu'avec l'adaptateur Net::HTTP et le fait que le streaming a été marqué pour la v1.0.
Il n'y a pas de feuille de route pour la v1.0 pour le moment, donc personne ne travaille activement sur le streaming pour le moment.

@iMacTia Je suis un peu déçu que vous disiez "personne ne travaille activement sur le streaming" car il semble que vous ayez écrasé le travail sur # 604 (également # 522, # 461) en disant "Tenez bon, ce sera dans la prochaine version" , mais ne travaille pas dessus. Pourquoi ne pas accepter les changements des communautés étant donné qu'il ne semble pas y avoir d'élan de la part de l'équipe principale ?

@jcoyne Je ne voulais pas dire que le streaming n'est pas encore disponible PARCE QUE "personne ne travaille activement sur le streaming". Je suis pleinement conscient que le fait que personne ne travaille dessus est principalement de ma faute. Cependant, j'ai expliqué pourquoi j'ai repoussé le # 604 et le problème n'était pas la mise en œuvre.
Afin de fusionner 604 dans l'un des éléments suivants, vous devez d'abord :

1. La prise en charge de tous les autres adaptateurs est ajoutée (actuellement, seul Net :: HTTP est pris en charge)
2. Nous attendons la version 1.0 car nous pourrions supprimer la prise en charge directe d'autres adaptateurs et les transformer en projets externes. Cela rendrait # 604 fusionnable tel qu'il est actuellement, mais malheureusement, cela n'a pas encore été convenu en interne.

Je m'excuse d'être lent et de ne pas avoir assez de temps pour investir dans le travail sur l'une des solutions ci-dessus.
Je comprends que vous seriez heureux de n'avoir que #604 fusionné parce que vous n'avez probablement besoin que de la prise en charge de Net :: HTTP, mais ce n'est pas ainsi que cela fonctionne lorsque vous devez maintenir une gemme et je ne peux pas le rendre aussi simple.

@iMacTia Je ne m'attends pas à ce que vous consacriez tous vos efforts à cette version, je suis juste frustré par les effets dissuasifs de la fermeture/du refus des demandes d'extraction sur lesquelles plusieurs personnes ont travaillé et qui n'ont aucun problème technique connu. Si vous n'avez pas le temps, n'est-il pas logique de laisser les autres vous aider ?

Je comprends pourquoi la prise en charge de tous les autres adaptateurs serait souhaitable, mais je pense que vous êtes trop strict avec votre interprétation du modèle d'adaptateur. Le modèle d'adaptateur exige une cohérence dans la manière dont vous effectuez une interaction, mais je ne dirais pas qu'il exige que chaque adaptateur prenne en charge toutes les fonctionnalités. Il existe de nombreuses bibliothèques utiles qui utilisent cette définition plus lâche (par exemple edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob::QueueAdapters-label-Backends+Features)

Pour être honnête, je suis personnellement d'accord sur vos dernières phrases.
J'aime le fonctionnement d'ActiveJob et le fait que vous puissiez ajouter des gemmes compatibles à votre application et les utiliser simplement comme QueueBackend (par exemple Sidekiq).

D'un autre côté, ce n'est pas la situation actuelle pour Faraday, ce n'est pas la vision originale de l'équipe de base et ce n'est pas ce à quoi tout le monde a été habitué.
Juste pour vous donner un exemple, dans #486 un utilisateur se plaint exactement de ce problème :

Je m'attendrais à ce que Faraday fonctionne uniquement lors du remplacement des adaptateurs.

Et c'est ce que @mislav et tout autre membre de l'équipe centrale ont appliqué depuis le début.
J'espère donc que vous comprendrez, comme je comprends parfaitement vos besoins, qu'en tant que dernier membre à rejoindre Faraday, je ne peux pas simplement jeter les décisions passées à la poubelle et commencer à faire ce que je veux. Ce qui signifie que le streaming doit être pris en charge par tous les adaptateurs avant que je puisse le fusionner dans le flux 0.x.
Exemples d'autres relations publiques fermées pour la même raison : #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment -145872698

Faraday 1.0 est différent, cela me donne beaucoup plus de liberté (je dois cependant préserver au maximum la rétrocompatibilité, cela ne veut pas dire que je peux faire ce que je veux 😅). Et c'est pourquoi j'ai suggéré de supprimer le support natif de tous les adaptateurs, mais plutôt de les déplacer vers des gemmes externes comme ce qui s'est passé avec Thypoeus. Cela aura beaucoup d'avantages et rendra la structure beaucoup plus similaire à ActiveJob , justifiant des choses comme le support partiel.
Pour cette raison, je considère le streaming comme une fonctionnalité 1.0 et j'ai dû geler les travaux dessus pour le moment.
Cela prendra beaucoup plus de temps, mais cela signifie faire les choses correctement pour moi. Je voudrais que ce soit aussi clair que possible : je ne ferme pas les relations publiques pour faire perdre du temps à qui que ce soit, j'essaie simplement d'aider à faire avancer ce projet (nous serions toujours en 0.9.x sinon) en honorant l'équipe principale vision.

Si vous n'avez pas le temps, n'est-il pas logique de laisser les autres vous aider ?

Juste une note finale à ce sujet : TOUT LE MONDE est le bienvenu pour aider. C'est ainsi que fonctionne l'Open Source ! Cependant, nous devons également respecter la vision de l'équipe centrale lorsque nous contribuons à quelque chose. On peut être d'accord avec eux comme pas d'accord (je ne suis pas d'accord avec eux sur certains points aussi !), mais il faut respecter leurs choix car si Faraday est ce qu'il est aujourd'hui, c'est sûrement grâce aux nombreux contributeurs, mais aussi grâce aux core team gérant tous les Issues/PRs et faisant avancer le projet de manière claire et logique (et croyez-moi, cette dernière prend beaucoup plus de temps que des contributions sporadiques). Si ce n'était pas pour eux de filtrer ou d'ajuster les entrées des contributeurs, nous pourrions connaître un Faraday complètement différent aujourd'hui, et je ne suis pas sûr qu'il serait meilleur que celui que nous connaissons réellement.

Ce problème a maintenant été converti en projet .