Faraday: 下一个大版本的功能列表

我正在寻找流媒体支持……有人在开发 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 合并到以下其中一项中，首先需要发生：

1. 添加了对所有其他适配器的支持（目前仅支持 Net::HTTP）
2. 我们等待 1.0 版，因为我们可能会删除对其他适配器的直接支持并将它们 gemify 到外部项目中。 这将使#604 可以像现在一样合并，但不幸的是，它尚未在内部达成一致。

对于速度缓慢且没有足够时间投资于上述任何解决方案，我深表歉意。
我知道您会对仅合并 #604 感到满意，因为您可能只需要对 Net::HTTP 的支持，但是当您必须维护 gem 时，它不是这样工作的，我不能让它那么简单。

@iMacTia我不希望您在此版本中投入所有精力，我只是对关闭/拒绝几个人已经处理并且没有已知技术问题的拉取请求的令人不寒而栗的影响感到沮丧。 如果你没有时间，让别人帮忙难道没有意义吗？

我理解为什么对所有其他适配器的支持是可取的，但我认为您对适配器模式的解释过于严格。 适配器模式要求您进行任何一次交互的方式保持一致，但我不会说它要求每个适配器都支持每个功能。 有许多有用的库使用这个更宽松的定义（例如 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 不同，这给了我更多的自由（我必须尽可能地保持向后兼容性，这并不意味着我可以做任何我想做的事情😅）。 这就是为什么我建议放弃对所有适配器的本机支持，而是将它们移到外部 gem 中，就像在 Thypoeus 中发生的那样。 这将有很多优势，并使结构更类似于ActiveJob ，证明部分支持之类的事情是合理的。
出于这个原因，我将流媒体视为 1.0 功能，我不得不暂时冻结它的工作。
这将需要更长的时间，但这意味着对我来说要正确地做事。 我想尽可能清楚地说明：我不是为了浪费任何人的时间而关闭 PR，我只是想帮助推动这个项目向前发展（否则我们仍然是 0.9.x）尊重核心团队想象。

如果你没有时间，让别人帮忙难道没有意义吗？

最后请注意：欢迎大家提供帮助。 这就是开源的工作原理！ 但是，当我们为某事做出贡献时，我们也应该尊重核心团队的愿景。 我们可以同意也可以不同意（我在某些方面也不同意他们的观点！），但我们必须尊重他们的选择，因为如果法拉第是今天的样子，那肯定要感谢许多贡献者，还要感谢核心团队管理所有问题/公关并以清晰和合乎逻辑的方式推进项目（相信我，后者比零星的贡献更耗时）。 如果不是他们过滤或调整贡献者的输入，我们今天可能会知道一个完全不同的法拉第，我不确定它会比我们实际知道的更好。

这个问题现在已经转换成一个项目。