ストリーミングサポートを探しています... 1.0に取り組んでいる人はいますか? ...そうでない場合は、なぜ他のPRが閉鎖されたのか😕
こんにちは@grosser 、理由はこのhttps://github.com/lostisland/faraday/pull/604#issuecomment-259125910で表現されています。
主な理由は、PRがNet::HTTP
アダプターとのみ互換性があり、ストリーミングがv1.0用にマークされているという事実でした。
現在、v1.0のロードマップはないため、当面、ストリーミングに積極的に取り組んでいる人は誰もいません。
@ iMacTia #604(#522、#461)の作業を「しっかり待ってください、これは次のリリースになります」と言って押しつぶされたように見えるので、「ストリーミングに積極的に取り組んでいる人は誰もいない」と言うのは少し残念です。 、しかしそれからそれに取り組んでいません。 コアチームによる勢いがないように思われるので、コミュニティの変更を受け入れてみませんか?
@jcoyne 「誰も積極的にストリーミングに取り組んでいない」ので、ストリーミングがまだ行われていないという意味ではありませんでした。 誰もそれに取り組んでいないという事実は主に私のせいであることを私は完全に承知しています。 しかし、なぜ私が#604を押し戻したのかを説明しましたが、問題は実装ではありませんでした。
604をマージするには、最初に次のいずれかを実行する必要があります。
上記のソリューションのいずれかに取り組むのに時間がかかり、十分な時間がないことをお詫び申し上げます。
おそらくNet :: HTTPのサポートのみが必要なため、#604のみをマージすることに満足していると思いますが、gemを維持する必要がある場合はそれが機能せず、単純にすることはできません。
@iMacTiaこのリリースに全力を注ぐことは期待していません。何人かの人々が取り組んできた、既知の技術的な問題がないプルリクエストを閉じる/拒否することの萎縮効果に不満を感じています。 時間がないのなら、他の人に手伝ってもらっても意味がありませんか?
他のすべてのアダプターのサポートが望ましい理由は理解していますが、アダプターパターンの解釈は厳しすぎると思います。 アダプターパターンは、1つの対話を行う方法の一貫性を要求しますが、すべてのアダプターがすべての機能をサポートすることを要求するとは言えません。 この緩い定義を使用する便利なライブラリがたくさんあります(例:edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob :: QueueAdapters-label-Backends + Features)
正直なところ、私はあなたの最後の文章に個人的に同意します。
ActiveJobの動作方法と、互換性のあるgemをアプリに追加して、それらをQueueBackend(Sidekiqなど)として使用できるという事実が気に入っています。
一方で、これはファラデーの現在の状況ではなく、コアチームの当初のビジョンではなく、誰もが慣れ親しんでいるものでもありません。
例を示すために、#486では、ユーザーがまさにこの問題について不満を言っています。
アダプターを交換するときにファラデーが機能することを期待しています。
そして、それは@mislavと他のコアチームメンバーが最初から実施したことです。
ですから、私はあなたのニーズを完全に理解しているので、ファラデーに参加する最後のメンバーとして、過去の決定を単純にビンに投げ入れて、やりたいことを始めることはできないことを理解していただければ幸いです。 つまり、ストリーミングを0.xフローにマージする前に、すべてのアダプターでストリーミングをサポートする必要があります。
同じ理由で閉鎖された他のPRの例:#485、#498、 https: //github.com/lostisland/faraday/pull/339#issuecomment -145872698
Faraday 1.0は異なり、より多くの自由を与えてくれます(ただし、下位互換性を可能な限り維持する必要がありますが、やりたいことが何でもできるという意味ではありません😅)。 そのため、すべてのアダプターのネイティブサポートを廃止することを提案しましたが、Thypoeusで発生したような外部のgemにアダプターを移動しました。 これには多くの利点があり、構造がActiveJob
に非常に似たものになり、部分的なサポートなどが正当化されます。
このため、ストリーミングは1.0の機能と見なしており、当面はその作業をフリーズする必要がありました。
かなり時間がかかりますが、それは私にとって適切に物事を行うことを意味します。 できるだけ明確にしたいと思います。誰かの時間を無駄にするためにPRを終了するのではなく、コアチームを称えてこのプロジェクトを推進するのを支援しようとしています(それ以外の場合は0.9.xのままです)。ヴィジョン。
時間がないのなら、他の人に手伝ってもらっても意味がありませんか?
これに関する最後の注意:誰もが助けてくれることを歓迎します。 それがオープンソースの仕組みです! ただし、何かに貢献するときは、コアチームのビジョンも尊重する必要があります。 私たちは彼らに賛成することも反対することもできますが(私もいくつかの点で彼らに反対します!)、ファラデーが今日のようであるならば、それは確かに多くの貢献者のおかげであるだけでなく、すべての問題/ PRを管理し、プロジェクトを明確かつ論理的な方法で進行させるコアチーム(そして私を信じて、後者は散発的な貢献よりもはるかに時間がかかります)。 彼らが寄稿者の入力をフィルタリングまたは調整していなかったとしたら、今日はまったく異なるファラデーを知っているかもしれません。実際に知っているファラデーよりも良いかどうかはわかりません。
この問題は現在、プロジェクトに変換されています。
最も参考になるコメント
正直なところ、私はあなたの最後の文章に個人的に同意します。
ActiveJobの動作方法と、互換性のあるgemをアプリに追加して、それらをQueueBackend(Sidekiqなど)として使用できるという事実が気に入っています。
一方で、これはファラデーの現在の状況ではなく、コアチームの当初のビジョンではなく、誰もが慣れ親しんでいるものでもありません。
例を示すために、#486では、ユーザーがまさにこの問題について不満を言っています。
そして、それは@mislavと他のコアチームメンバーが最初から実施したことです。
ですから、私はあなたのニーズを完全に理解しているので、ファラデーに参加する最後のメンバーとして、過去の決定を単純にビンに投げ入れて、やりたいことを始めることはできないことを理解していただければ幸いです。 つまり、ストリーミングを0.xフローにマージする前に、すべてのアダプターでストリーミングをサポートする必要があります。
同じ理由で閉鎖された他のPRの例:#485、#498、 https: //github.com/lostisland/faraday/pull/339#issuecomment -145872698
Faraday 1.0は異なり、より多くの自由を与えてくれます(ただし、下位互換性を可能な限り維持する必要がありますが、やりたいことが何でもできるという意味ではありません😅)。 そのため、すべてのアダプターのネイティブサポートを廃止することを提案しましたが、Thypoeusで発生したような外部のgemにアダプターを移動しました。 これには多くの利点があり、構造が
ActiveJob
に非常に似たものになり、部分的なサポートなどが正当化されます。このため、ストリーミングは1.0の機能と見なしており、当面はその作業をフリーズする必要がありました。
かなり時間がかかりますが、それは私にとって適切に物事を行うことを意味します。 できるだけ明確にしたいと思います。誰かの時間を無駄にするためにPRを終了するのではなく、コアチームを称えてこのプロジェクトを推進するのを支援しようとしています(それ以外の場合は0.9.xのままです)。ヴィジョン。
これに関する最後の注意:誰もが助けてくれることを歓迎します。 それがオープンソースの仕組みです! ただし、何かに貢献するときは、コアチームのビジョンも尊重する必要があります。 私たちは彼らに賛成することも反対することもできますが(私もいくつかの点で彼らに反対します!)、ファラデーが今日のようであるならば、それは確かに多くの貢献者のおかげであるだけでなく、すべての問題/ PRを管理し、プロジェクトを明確かつ論理的な方法で進行させるコアチーム(そして私を信じて、後者は散発的な貢献よりもはるかに時間がかかります)。 彼らが寄稿者の入力をフィルタリングまたは調整していなかったとしたら、今日はまったく異なるファラデーを知っているかもしれません。実際に知っているファラデーよりも良いかどうかはわかりません。