Faraday: Lista de funciones para los próximos grandes lanzamientos

Estoy buscando soporte de transmisión... ¿alguien está trabajando en 1.0? ... si no por que se cerro el otro PR 😕

Hola @grosser , las razones se expresan en este https://github.com/lostisland/faraday/pull/604#issuecomment -259125910.
La razón principal fue que el PR solo era compatible con el adaptador Net::HTTP y el hecho de que la transmisión se marcó para v1.0.
No hay una hoja de ruta para v1.0 en este momento, por lo que nadie está trabajando activamente en la transmisión por el momento.

@iMacTia Estoy un poco decepcionado de que diga "nadie está trabajando activamente en la transmisión" porque parece que aplastó el trabajo en el n. ° 604 (también en el n. , pero luego no trabajar en ello. ¿Por qué no aceptar los cambios de las comunidades considerando que no parece haber un impulso por parte del equipo central?

@jcoyne No quise decir que la transmisión aún no está en marcha PORQUE "nadie está trabajando activamente en la transmisión". Soy plenamente consciente de que el hecho de que nadie esté trabajando en ello es principalmente culpa mía. Sin embargo, expliqué por qué rechacé el n. ° 604 y el problema no fue la implementación.
Para que 604 se fusione en uno de los siguientes debe suceder primero:

1. Se agrega soporte para todos los demás adaptadores (en este momento solo se admite Net::HTTP)
2. Esperamos la versión 1.0 porque podríamos eliminar el soporte directo para otros adaptadores y convertirlos en proyectos externos. Eso haría que #604 se pueda fusionar tal como está ahora, pero desafortunadamente aún no se ha acordado internamente.

Me disculpo por ser lento y no tener suficiente tiempo para invertir en trabajar en cualquiera de las soluciones anteriores.
Entiendo que estaría contento con tener solo #604 fusionado porque probablemente solo necesite soporte para Net::HTTP, pero no es así como funciona cuando tiene que mantener una gema y no puedo hacerlo así de simple.

@iMacTia No espero que ponga todo su esfuerzo en este lanzamiento, solo estoy frustrado por los efectos escalofriantes de cerrar/rechazar las solicitudes de extracción en las que varias personas han trabajado y no tienen problemas técnicos conocidos. Si no tienes tiempo, ¿no tiene sentido dejar que otros te ayuden?

Entiendo por qué sería deseable la compatibilidad con todos los demás adaptadores, pero creo que es demasiado estricto con su interpretación del patrón del adaptador. El patrón del adaptador exige consistencia en la forma en que realiza cualquier interacción, pero no diría que exige que cada adaptador admita todas las funciones. Hay muchas bibliotecas útiles que usan esta definición más flexible (por ejemplo, edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob::QueueAdapters-label-Backends+Features)

Para ser honesto, personalmente estoy de acuerdo con sus últimas oraciones.
Me gusta la forma en que funciona ActiveJob y el hecho de que puede agregar gemas compatibles a su aplicación y simplemente usarlas como QueueBackend (por ejemplo, Sidekiq).

Por otro lado, esta no es la situación actual de Faraday, no es la visión original del equipo central y no es a lo que todos están acostumbrados.
Solo para darte un ejemplo, en el n. ° 486, un usuario se queja exactamente de este problema:

Esperaría que Faraday solo funcione al cambiar los adaptadores.

Y eso es lo que @mislav y cualquier otro miembro del equipo central impusieron desde el principio.
Así que espero que entiendas, como entiendo totalmente tus necesidades, que como el último miembro que se unió a Faraday no puedo simplemente tirar las decisiones pasadas a la basura y empezar a hacer lo que quiero. Lo que significa que la transmisión debe ser compatible con todos los adaptadores antes de que pueda fusionarla en el flujo 0.x.
Ejemplos de otros PR cerrados por la misma razón: #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment -145872698

Faraday 1.0 es diferente, eso me da mucha más libertad (aunque tengo que preservar la compatibilidad con versiones anteriores tanto como sea posible, eso no significa que pueda hacer lo que quiera 😅). Y es por eso que sugerí eliminar el soporte nativo para todos los adaptadores, y moverlos a gemas externas como sucedió con Thypoeus. Esto tendrá muchas ventajas y hará que la estructura sea mucho más similar a ActiveJob , justificando cosas como el soporte parcial.
Por esta razón, veo la transmisión como una función 1.0 y tuve que congelar los trabajos por el momento.
Tomará mucho más tiempo, pero eso significa hacer las cosas correctamente para mí. Me gustaría dejarlo lo más claro posible: no estoy cerrando las relaciones públicas para hacer perder el tiempo a nadie, simplemente estoy tratando de ayudar a impulsar este proyecto (de lo contrario, seguiríamos siendo 0.9.x) honrando al equipo central. visión.

Si no tienes tiempo, ¿no tiene sentido dejar que otros te ayuden?

Solo una nota final sobre esto: TODOS son bienvenidos a ayudar. ¡Así es como funciona el código abierto! Sin embargo, también debemos respetar la visión del equipo central cuando contribuimos a algo. Podemos estar de acuerdo con ellos y también en desacuerdo (¡yo también estoy en desacuerdo con ellos en algunos puntos!), pero tenemos que respetar sus elecciones porque si Faraday es lo que es hoy, seguramente sea gracias a los muchos colaboradores, pero también gracias a la equipo central gestionando todos los problemas/RP y avanzando en el proyecto de una manera clara y lógica (y créanme, esto último requiere mucho más tiempo que las contribuciones esporádicas). Si no fuera por ellos filtrando o ajustando las entradas de los contribuyentes, hoy podríamos conocer un Faraday completamente diferente, y no estoy seguro de que sea mejor que el que realmente conocemos.

Este problema ahora se ha convertido en un proyecto .