Reconsider SafeYAML gem dependency about faraday_middleware

[olleolleolle]

Hello @d-m-u and thanks for the offer!

Apologies for a late reply. This is a big topic, so I have taken my time preparing to write this. 🕚

Overview: 🗺️ The Faraday Middleware repository does not have the goal to grow, but to shrink. Any new middlewares are better created as their own projects, their own repository and release process. This reduces the maintenance burden on the Faraday team, to build the main software, and not this collection of middlewares.

I have talked about this with the other maintainers, and they also wish to be able to concentrate on the Faraday project. (👋 @iMacTia & friends.)

Idea: 💭 Perhaps the time has come for the YAML middleware to take wings, and have a new repository home, so that it can be deprecated to be removed in the next major version?

Doing that would free that library's author up to pick a support schedule (say, Ruby's own Ruby Maintenance Branches, or an even smaller surface of support). The search space of options above is perhaps too big for Faraday Middleware - for a new gem, it could be cut down a lot.

By creating a pattern to follow when creating a new Faraday middleware project, we help the wider Faraday community serve its own needs.

Offer: 👉 If you'd like to pick an implementation path and go forward with this, I would support you. How do you feel about all this?

[olleolleolle]

@d-m-u faraday-http is a just-released Faraday-hosted example of an Adapter (outside the core project).

It's an example of a non-core gem (not a middleware, but an adapter).

Perhaps interesting for you.

[d-m-u]

hey @olleolleolle I'd be happy to tackle this if given a bit of guidance as to how you'd like to handle the way forward.

[d-m-u]

This sounds great and I'm absolutely willing to try!