Faraday: Список функций для следующих больших выпусков

Я ищу поддержку потоковой передачи ... кто-нибудь работает над 1.0? ... если нет, то почему другой PR был закрыт 😕

Привет @grosser , причины изложены в этом https://github.com/lostisland/faraday/pull/604#issuecomment -259125910.
Основная причина заключалась в том, что PR был совместим только с адаптером Net::HTTP и тот факт, что потоковая передача была отмечена для версии 1.0.
На данный момент нет дорожной карты для версии 1.0, поэтому пока никто активно не работает над потоковой передачей.

@iMacTia Я немного разочарован тем, что вы говорите «никто активно не работает над потоковой передачей», потому что, похоже, вы раздавили работу над # 604 (также # 522, # 461), сказав: «Держись, это будет в следующем выпуске» , но тогда не работает над этим. Почему бы не принять изменения сообщества, учитывая, что основная команда не проявляет инициативы?

@jcoyne Я не имел в виду, что потоковой передачи еще нет, ПОТОМУ ЧТО «никто активно не работает над потоковой передачей». Я полностью осознаю, что тот факт, что над ним никто не работает, в основном моя вина. Однако я объяснил, почему отказался от #604, и проблема была не в реализации.
Для того, чтобы 604 объединились в одном из следующих случаев, необходимо сначала выполнить одно из следующих действий:

1. Добавлена ​​поддержка всех остальных адаптеров (сейчас поддерживается только Net::HTTP)
2. Мы ждем версию 1.0, потому что мы можем удалить прямую поддержку других адаптеров и превратить их во внешние проекты. Это сделало бы № 604 объединяемым, как сейчас, но, к сожалению, это еще не согласовано внутри.

Приношу извинения за медлительность и нехватку времени для работы над любым из вышеперечисленных решений.
Я понимаю, что вы были бы довольны слиянием только #604, потому что вам, вероятно, нужна только поддержка Net::HTTP, но это не так, когда вам нужно поддерживать гем, и я не могу просто сделать это так просто.

@iMacTia Я не ожидаю, что вы бросите все свои усилия на этот выпуск, я просто разочарован пугающими эффектами закрытия / отклонения запросов на вытягивание, над которыми работали несколько человек и у которых нет известных технических проблем. Если у вас нет времени, разве не имеет смысла позволить другим помочь?

Я понимаю, почему желательна поддержка всех других адаптеров, но я думаю, что вы слишком строго интерпретируете шаблон адаптера. Шаблон адаптера требует согласованности в том, как вы выполняете любое взаимодействие, но я бы не сказал, что он требует, чтобы каждый адаптер поддерживал каждую функцию. Существует множество полезных библиотек, использующих это более свободное определение (например, edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob::QueueAdapters-label-Backends+Features).

Честно говоря, я лично согласен с вашими последними предложениями.
Мне нравится, как работает ActiveJob, и тот факт, что вы можете добавлять совместимые драгоценные камни в свое приложение и просто использовать их в качестве QueueBackend (например, Sidekiq).

С другой стороны, это не текущая ситуация для Фарадея, это не первоначальное видение основной команды и не то, к чему все привыкли.
Просто чтобы привести вам пример, в # 486 пользователь жалуется именно на эту проблему:

Я ожидаю, что Фарадей будет работать только при замене адаптеров.

И это то, что @mislav и любой другой член основной команды навязывали с самого начала.
Поэтому я надеюсь, что вы поймете, как я полностью понимаю ваши потребности, что как последний член, присоединившийся к Фарадею, я не могу просто выбросить прошлые решения в мусорное ведро и начать делать то, что я хочу. Это означает, что потоковая передача должна поддерживаться всеми адаптерами, прежде чем я смогу объединить ее с потоком 0.x.
Примеры других закрытых по той же причине PR: #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment -145872698

Faraday 1.0 отличается, что дает мне гораздо больше свободы (хотя я должен максимально сохранить обратную совместимость, это не значит, что я могу делать все, что захочу 😅). И именно поэтому я предложил отказаться от встроенной поддержки всех адаптеров, а вместо этого перенести их во внешние драгоценные камни, как это произошло с Thypoeus. Это будет иметь много преимуществ и сделает структуру более похожей на ActiveJob , оправдывая такие вещи, как частичная поддержка.
По этой причине я рассматриваю потоковую передачу как функцию 1.0, и мне пришлось временно приостановить работу над ней.
Это займет гораздо больше времени, но для меня это означает делать все правильно. Я хотел бы сделать это как можно более ясным: я не закрываю PR ради того, чтобы тратить чье-то время, я просто пытаюсь помочь продвинуть этот проект вперед (иначе мы все еще были бы 0.9.x), чествуя основную команду зрение.

Если у вас нет времени, разве не имеет смысла позволить другим помочь?

И последнее замечание по этому поводу: каждый может помочь. Вот как работает Open Source! Однако мы также должны уважать видение основной команды, когда мы вносим свой вклад. Мы можем как соглашаться с ними, так и не соглашаться (я тоже не согласен с ними по некоторым пунктам!), но мы должны уважать их выбор, потому что если Фарадей является тем, чем он является сегодня, то это, безусловно, благодаря многим участникам, а также благодаря основная команда, управляющая всеми проблемами / связями с общественностью и продвигающая проект четким и логичным образом (и поверьте мне, последнее требует гораздо больше времени, чем спорадические вклады). Если бы они не фильтровали или корректировали входные данные участников, мы могли бы знать сегодня совершенно другого Фарадея, и я не уверен, что он был бы лучше, чем тот, который мы знаем на самом деле.

Теперь этот выпуск преобразован в проект .