Faraday: Liste der Features für die nächsten großen Releases

Ich suche Streaming-Unterstützung ... arbeitet jemand an 1.0? ... wenn nicht warum wurde der andere PR geschlossen 😕

Hallo @grosser , Gründe werden in diesem https://github.com/lostisland/faraday/pull/604#issuecomment -259125910 ausgedrückt.
Hauptgrund war, dass der PR nur mit Net::HTTP -Adapter kompatibel war und dass Streaming für v1.0 markiert wurde.
Derzeit gibt es keine Roadmap für v1.0, daher arbeitet derzeit niemand aktiv am Streaming.

@iMacTia Ich bin ein bisschen enttäuscht, dass du sagst „Niemand arbeitet aktiv am Streaming“, weil du anscheinend die Arbeit an #604 (auch #522, #461) gequetscht hast, indem du gesagt hast: „Moment mal, das wird in der nächsten Version sein.“ , aber dann nicht daran arbeiten. Warum nicht die Community-Änderungen akzeptieren, wenn man bedenkt, dass das Kernteam keine Dynamik zu zeigen scheint?

@jcoyne Ich meinte nicht, dass Streaming noch nicht da ist, WEIL "niemand aktiv am Streaming arbeitet". Mir ist vollkommen bewusst, dass die Tatsache, dass niemand daran arbeitet, hauptsächlich meine Schuld ist. Ich habe jedoch erklärt, warum ich auf #604 zurückgedrängt habe und das Problem nicht die Implementierung war.
Um 604 zusammenzuführen, muss zuerst eines der folgenden Dinge geschehen:

1. Unterstützung für alle anderen Adapter wurde hinzugefügt (derzeit wird nur Net::HTTP unterstützt)
2. Wir warten auf Version 1.0, da wir möglicherweise die direkte Unterstützung für andere Adapter entfernen und sie in externe Projekte gemifizieren. Das würde #604 so wie es jetzt ist fusionierbar machen, aber leider wurde es intern noch nicht abgestimmt.

Ich entschuldige mich dafür, dass ich langsam bin und nicht genug Zeit habe, um an einer der oben genannten Lösungen zu arbeiten.
Ich verstehe, dass Sie damit zufrieden wären, nur #604 gemergt zu haben, weil Sie wahrscheinlich nur Unterstützung für Net::HTTP benötigen, aber so funktioniert es nicht, wenn Sie ein Juwel warten müssen, und ich kann es nicht einfach so machen.

@iMacTia Ich erwarte nicht, dass Sie all Ihre Mühe in diese Version stecken, ich bin nur frustriert über die abschreckenden Auswirkungen des Schließens/Ablehnens von Pull-Requests, an denen mehrere Personen gearbeitet haben und die keine bekannten technischen Probleme haben. Wenn Sie keine Zeit haben, ist es nicht sinnvoll, sich von anderen helfen zu lassen?

Ich verstehe, warum die Unterstützung aller anderen Adapter wünschenswert wäre, aber ich denke, Sie sind mit Ihrer Interpretation des Adaptermusters zu streng. Das Adaptermuster erfordert Konsistenz in der Art und Weise, wie Sie eine Interaktion durchführen, aber ich würde nicht sagen, dass es verlangt, dass jeder Adapter jede Funktion unterstützt. Es gibt viele nützliche Bibliotheken, die diese lockerere Definition verwenden (zB edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob::QueueAdapters-label-Backends+Features)

Ehrlich gesagt stimme ich Ihren letzten Sätzen persönlich zu.
Ich mag die Funktionsweise von ActiveJob und die Tatsache, dass Sie Ihrer App kompatible Edelsteine ​​hinzufügen und sie einfach als QueueBackend (z. B. Sidekiq) verwenden können.

Auf der anderen Seite ist dies nicht die aktuelle Situation für Faraday, es ist nicht die ursprüngliche Vision des Kernteams und es ist nicht das, woran alle gewöhnt sind.
Nur um Ihnen ein Beispiel zu geben, in #486 beschwert sich ein Benutzer über genau dieses Problem:

Ich würde erwarten, dass Faraday nur funktioniert, wenn Adapter ausgetauscht werden.

Und das haben @mislav und alle anderen Mitglieder des Kernteams von Anfang an durchgesetzt.
Ich hoffe, Sie werden verstehen, wie ich Ihre Bedürfnisse vollkommen verstehe, dass ich als letztes Mitglied, das Faraday beigetreten ist, nicht einfach die vergangenen Entscheidungen in den Müll werfen und anfangen kann, das zu tun, was ich will. Das bedeutet, dass Streaming von allen Adaptern unterstützt werden muss, bevor ich es in den 0.x-Flow einbinden kann.
Beispiele für andere PRs, die aus demselben Grund geschlossen wurden: #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment -145872698

Faraday 1.0 ist anders, das gibt mir viel mehr Freiheit (ich muss die Abwärtskompatibilität jedoch so weit wie möglich wahren, das bedeutet nicht, dass ich tun kann, was ich will 😅). Und deshalb habe ich vorgeschlagen, die native Unterstützung für alle Adapter einzustellen und sie stattdessen in externe Juwelen zu verschieben, wie es bei Thypoeus der Fall war. Dies hat viele Vorteile und macht die Struktur viel ähnlicher zu ActiveJob , was Dinge wie teilweise Unterstützung rechtfertigt.
Aus diesem Grund sehe ich Streaming als 1.0-Feature und musste die Arbeiten daran vorerst einfrieren.
Es wird viel länger dauern, aber das bedeutet für mich, die Dinge richtig zu machen. Ich möchte es so klar wie möglich machen: Ich schließe die PR nicht, um jemandes Zeit zu verschwenden, ich versuche einfach zu helfen, dieses Projekt voranzutreiben (wir wären sonst immer noch 0.9.x), um das Kernteam zu ehren Vision.

Wenn Sie keine Zeit haben, ist es nicht sinnvoll, sich von anderen helfen zu lassen?

Nur noch eine letzte Anmerkung dazu: JEDER kann helfen. So funktioniert Open Source! Wir sollten jedoch auch die Vision des Kernteams respektieren, wenn wir zu etwas beitragen. Wir können ihnen sowohl zustimmen als auch widersprechen (ich stimme ihnen auch in einigen Punkten nicht zu!), aber wir müssen ihre Entscheidungen respektieren, denn wenn Faraday das ist, was es heute ist, dann dank der vielen Mitwirkenden, aber auch dank der Kernteam, das alle Probleme/PRs verwaltet und das Projekt auf klare und logische Weise vorantreibt (und glauben Sie mir, letzteres ist viel zeitaufwändiger als sporadische Beiträge). Wenn sie die Eingaben der Mitwirkenden nicht gefiltert oder angepasst hätten, würden wir heute vielleicht einen völlig anderen Faraday kennen, und ich bin mir nicht sicher, ob er besser wäre als der, den wir tatsächlich kennen.

Diese Ausgabe wurde nun in ein Projekt umgewandelt.