Faraday: List of features for the next big releases

Created on 18 Oct 2016  ·  7Comments  ·  Source: lostisland/faraday

Faraday 1.0

  • [x] Set minimum Ruby version to >= 2.2
  • [x] Streaming (Net::HTTP) #604
  • [x] Change the way adapters are managed #47 #121
  • [ ] API improvements #241 #305 #462 #517 #693 #718 #735
  • [ ] Pull out adapters as separate gems. Faraday-Typheous, Faraday-Patron, etc. #112
  • [ ] Supports IPv6 #621
  • [ ] Streaming (others)
  • [ ] Improve documentation/Readme #425 #575
  • [ ] Improve Codeclimate maintainability (https://codeclimate.com/github/lostisland/faraday)
  • [ ] Pass the entire project through Rubocop and set it up on Github as an integration
  • [ ] Improve Wiki adding more examples an how-to
  • [x] Convert tests to RSpec?
  • [x] Setup Github integration for test coverage and code metrics
  • [ ] Remove all deprecated methods/behaviours (with related warnings)

Most helpful comment

To be honest, I personally agree on your last sentences.
I like the way ActiveJob works and the fact that you can add compatible gems to your app and just use them as a QueueBackend (e.g. Sidekiq).

On the other side, this is not the current situation for Faraday, it's not the original vision of the core team and it's not what everyone have been used to.
Just to make an example to you, in #486 a user is complaining about exactly this issue:

I'd expect Faraday to just work when swapping out adapters.

And that's what @mislav and any other core team member enforced from the beginning.
So I hope you'll understand, as I totally understand your needs, that as the last member joining Faraday I can't simply throw the past decisions in the bin and start doing what I want. Which means that streaming have to be supported by all adapters before I can merge it in the 0.x flow.
Examples of other PRs closed for the same reason: #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment-145872698

Faraday 1.0 is different, that gives me much more freedom (I do have to preserve backward-compatibility as much as possible though, it doesn't mean I can do whatever I want 😅). And that's why I suggested to drop native support for all adapters, but rather moving them into external gems like what happened with Thypoeus. This will have a lot of advantages and will make the structure much more similar to ActiveJob, justifying things like partial-support.
For this reason, I see streaming as a 1.0 feature and I had to freeze works on it for the time being.
It will take much longer, but that means doing things properly to me. I would like to make it as clear as possible: I'm not closing PR for the sake of wasting anyone's time, I'm simply trying to help pushing this project forward (we would still be 0.9.x otherwise) honouring the core team vision.

If you don't have the time, doesn't it make sense to let others help?

Just a final note on this: EVERYONE is welcome to help. That's how Open Source works! However, we should also respect the core team's vision when we contribute to something. We can agree with them as well as disagree (I disagree with them on some points too!), but we have to respect their choices because if Faraday is what it is today, it's surely thanks to the many contributors, but also thanks to the core team managing all the Issues/PRs and progressing the project in a clear and logical way (and believe me, the latter is much more time consuming than sporadic contributions). If it wasn't for them filtering or adjusting contributors inputs, we might know a completely different Faraday today, and I'm not sure it would be better than the one we actually know.

All 7 comments

I'm looking for streaming support ... is anyone working on 1.0 ? ... if not why was the other PR closed 😕

Hi @grosser, reasons are expressed in this https://github.com/lostisland/faraday/pull/604#issuecomment-259125910.
Main reason was that the PR was only compatible with Net::HTTP adapter and the fact that streaming have been marked for v1.0.
There's no roadmap for v1.0 at the moment, so no one actively working on streaming for the time being.

@iMacTia I'm a bit disappointed that you say "no one actively working on streaming" because it seems you squashed work on #604 (also #522, #461) by saying "Hold tight, this will be in the next release", but then not working on it. Why not accept the communities changes considering there doesn't seem to be momentum by the core team?

@jcoyne I didn't mean that streaming is not in yet BECAUSE "no one actively working on streaming". I'm fully aware that the fact no one is working on it is mainly my fault. However, I've explained why I pushed back on #604 and the problem was not the implementation.
In order to get 604 merged in one of the following needs to happen first:

  1. Support for all the other adapters is added (right now only Net::HTTP is supported)
  2. We wait for version 1.0 because we might remove direct support for other adapters and gemify them into external projects. That would make #604 mergeable as it is now, but unfortunately it has not been agreed internally yet.

I apologise for being slow and not having enough time to invest in working on any of the above solutions.
I understand you'd be happy with having only #604 merged because you probably only need support for Net::HTTP, but that's not how it works when you have to maintain a gem and I can't just make it that simple.

@iMacTia I don't expect that you throw all your effort into this release, I'm just frustrated about the chilling effects of closing/denying pull requests that several people have worked on and have no known technical problems. If you don't have the time, doesn't it make sense to let others help?

I understand why support for all other adapters would be desirable, but I think you are overly strict with your interpretation the adapter pattern. The adapter pattern demands consistency of the manner you do any one interaction, but I wouldn't say it demands that every adapter support every feature. There are many useful libraries out there that use this looser definition (e.g. edgeapi.rubyonrails.org/classes/ActiveJob/QueueAdapters.html#module-ActiveJob::QueueAdapters-label-Backends+Features)

To be honest, I personally agree on your last sentences.
I like the way ActiveJob works and the fact that you can add compatible gems to your app and just use them as a QueueBackend (e.g. Sidekiq).

On the other side, this is not the current situation for Faraday, it's not the original vision of the core team and it's not what everyone have been used to.
Just to make an example to you, in #486 a user is complaining about exactly this issue:

I'd expect Faraday to just work when swapping out adapters.

And that's what @mislav and any other core team member enforced from the beginning.
So I hope you'll understand, as I totally understand your needs, that as the last member joining Faraday I can't simply throw the past decisions in the bin and start doing what I want. Which means that streaming have to be supported by all adapters before I can merge it in the 0.x flow.
Examples of other PRs closed for the same reason: #485, #498, https://github.com/lostisland/faraday/pull/339#issuecomment-145872698

Faraday 1.0 is different, that gives me much more freedom (I do have to preserve backward-compatibility as much as possible though, it doesn't mean I can do whatever I want 😅). And that's why I suggested to drop native support for all adapters, but rather moving them into external gems like what happened with Thypoeus. This will have a lot of advantages and will make the structure much more similar to ActiveJob, justifying things like partial-support.
For this reason, I see streaming as a 1.0 feature and I had to freeze works on it for the time being.
It will take much longer, but that means doing things properly to me. I would like to make it as clear as possible: I'm not closing PR for the sake of wasting anyone's time, I'm simply trying to help pushing this project forward (we would still be 0.9.x otherwise) honouring the core team vision.

If you don't have the time, doesn't it make sense to let others help?

Just a final note on this: EVERYONE is welcome to help. That's how Open Source works! However, we should also respect the core team's vision when we contribute to something. We can agree with them as well as disagree (I disagree with them on some points too!), but we have to respect their choices because if Faraday is what it is today, it's surely thanks to the many contributors, but also thanks to the core team managing all the Issues/PRs and progressing the project in a clear and logical way (and believe me, the latter is much more time consuming than sporadic contributions). If it wasn't for them filtering or adjusting contributors inputs, we might know a completely different Faraday today, and I'm not sure it would be better than the one we actually know.

This issue has now been converted into a project.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Carlbc18 picture Carlbc18  ·  23Comments

jasnow picture jasnow  ·  9Comments

mattbrictson picture mattbrictson  ·  10Comments

sferik picture sferik  ·  26Comments

gjtorikian picture gjtorikian  ·  18Comments