Integrate oauth?

[Fristi]

Hi,

While using http, you often have to deal with oauth2. There's usually some code around which manages these interactions by keeping a atomic ref with the needed token. However there is already this great library which does that in a generic way: https://github.com/ocadotechnology/sttp-oauth2/

Would it be an idea to integrate this into sttp it self ? Or propose to transfer their repository? I think the activity is quite low, not sure if it's still active.

Great to hear you opinions, have a good day!

Pinging @majk-p @kubukoz

[majk-p]

Hi @Fristi
I'm glad you found sttp-oauth2 useful! To my best knowledge @zstoychev and his team are the current maintainers of the library. I reached out to the team to ask if they are willing to transfer the project and will update you when they respond.

Would it be an idea to integrate this into sttp it self?

I think sttp-oauth2 makes sense as a separate project. The main benefit being the separate release process and versioning. Those projects evolve at different rate and common versioning wouldn't make a lot of sense.

Or propose to transfer their repository?

Should both sides decide for the transfer, I'm happy to help

Disclaimer: I'm no longer with Ocado Technology, speaking solely for myself as ex-maintainer of sttp-oauth2

[adamw]

Thanks for reaching out. While I'm not sure if the current maintainers would want any ownership transfer in the first place, so that's all very hypothetical, but even if, I can't say that we would have any capacity to evolve the project further. We could plug it into our automated update / release processes (that would be a one-off task), but I wouldn't want to make any promises or take responsibility for fixing issues / adding features. So just FYI :)

[Fristi]

I reached out to the team to ask if they are willing to transfer the project and will update you when they respond.

Let's see what they would like :)

I think sttp-oauth2 makes sense as a separate project. The main benefit being the separate release process and versioning. Those projects evolve at different rate and common versioning wouldn't make a lot of sense.

Agreed, but having it integrated in one active project with a release cycle which is regular, the dependencies and new features (if they get contributed) are being released

We could plug it into our automated update / release processes (that would be a one-off task), but I wouldn't want to make any promises or take responsibility for fixing issues / adding features. So just FYI :)

I think having updated dependencies and an automatic release process in place is already valuable!

Thing is with some integration modules in open source (no matter what eco system) world is that they are incredible valuable, it happens quite a lot that the maintainers stop it. If it's still being released and updated within another library I think it's a great win for the eco system

[majk-p]

I agree with @Fristi, having automated updates + releases is a value on it's own. The project could be marked as contribution-first.

Let's hear from current maintainers first.

[zstoychev]

Hi everyone,

I am from Ocado Technology, the maintainers of the library. Michal got in contact with us. We discussed this internally and we would be happy if sttp-ouath2 can find a home closer to the community and to transfer ownership if there is interest to take it as we are low in capacity to be able to maintain it well.

Let us know what your thoughts are.

[majk-p]

Thanks, @zstoychev!

Due to the limited capacity @adamw mentioned on their side, we can transfer the project to https://github.com/polyvariant/ where we can provide low-effort maintenance. This makes sense, considering I am the initial author of this code. If that works we can discuss the transfer details in private.

What do you think?

[Fristi]

What if we would transfer it to softwaremill anyway and get contributor permissions or alternatively integrate it into the build of sttp? Having at softwaremill has better publicity reach and therefore more likelihood to get more contributions :) Of course softwaremill would want to do this of course :)

[adamw]

I think keeping it as a separate project makes most sense. The build of sttp is big enough already :)

Also, maybe the decision would be best made by the new maintainers? I can of course give contributor permissions if the project were to end up on our account, but https://github.com/polyvariant/ seems to be a great place as well. For publicity, we'll for sure link from the docs (I think we do already), so that should be taken care of :)

[majk-p]

If we are to maintain the project (with the help of others in Polyvariant), it would be best to do it within our own organization. We are not affiliated with SoftwareMill and do not want to give the false impression that there is any responsibility on their side.

As per visibility - transferring the project on Github should automatically redirect all links so bookmarks and search results should remain relevant. This will require a proper communication with the community as well of course.

[Fristi]

I understand, was hoping to bring more people together to bundle the efforts in all the work which has been done so far!

I think it's already great that the work of sttp-oauth will continue somewhere else ❤️

[majk-p]

was hoping to bring more people together

We are very open to contributions!

[Fristi]

@zstoychev When would you able to transfer the repository? I've got a ZIO PR ready :)

[majk-p]

@Fristi I discussed that with Zdravko and I'll be doing the transfer. I want to put up a migration plan today. If all goes well we should finish migration+housekeeping this week 😉

[majk-p]

The transfer plan is ready polyvariant/sttp-oauth2#477. Looking forward for your input before I proceed.

I think we can close this issue and continue there

[zstoychev]

Polyvariant looks a great option, thank you Michal for driving this!

[Fristi]

Repository has been migrated, thanks everybody for your input !