Shutting this project down

[technoweenie]

This project is incomplete, and isn't seeing any new work. I don't have any time to work on it, and unfortunately need to shut it down :( I'm not going to yank any gem versions, but I won't be replying to issues or pull requests from here on out.

You're probably better off with Faraday if you can't decide which of ruby's many http clients you want to use.

[georgeguimaraes]

Thank you for all your effort on hurley. <3

[christhekeele]

Should this lostisland/faraday#454 issue be closed then?

I just came back to this project, after having last heard about it through that issue, to start replacing my Faraday code, only to discover hurley had come and gone. :/

[aaronchi]

😢

[zekefast]

@technoweenie will you consider if somebody catch up this project? It seems from architecture point of view this project much better then Faraday.

[technoweenie]

@zekefast I think I'd prefer you to fork and rename it. Hurley is kind of a dumb name anyway :)

[halostatue]

@technoweenie Do you have anything that would suggest the architectural direction you thought appropriate? My team at Kinetic Cafe has found Hurley to be useful over the last year and plan on forking and renaming, but we want to make sure we have an appropriate understanding before we start introducing our own ideas. @ravster would be our lead on this.

Thanks so much for this and Faraday both.

[zekefast]

@technoweenie Thank you for starting this and Faraday! As @halostatue mentioned it would be interesting to here you architectural plans about it if you had some. Thanks!

@halostatue, @ravster have you, guys, made some progress on this already? Please, point me where I can found you plans on this project. So I do not need to make one more fork of this.

[halostatue]

@zekefast we have not yet started this and probably won’t for a week or so. Our fork is currently at KineticCafe/hurley but we will be renaming it as @technoweenie has requested once we come up with a good name.

[technoweenie]

The only thing I've written about Hurley outside of its code/README is lostisland/faraday#454. That outlines my initial goals. The big one was dropping the rack-inspired middleware system, into before and after callbacks on a Hurley::Client. I was also inspired by Go's HTTP client.

One really common Faraday question was how to test a built faraday stack. Since the stack is just an array of middleware, you'd have to know the adapter's exact array index in the stack. I think most people just create some factory method that takes a faraday adapter (net/http, typhoeus, etc).

I prefer Hurley's client callbacks to the rack middleware.

FWIW I really like Hurley, and may even help out on the renamed project. I just don't have the bandwidth to lead the project right now. Figured it'd be better to just put it out of its misery now before more people start depending on it in their projects.

[christhekeele]

I've been tinkering with a Faraday/Hurley inspired library for the past few months, finally sitting down and extracting it fully now.

It follows the direction Hurley was headed, but the implementation has a few extra design goals:

• It represents all components of HTTP calls with plain-old ruby value objects. This makes it easy to add behavior the Ruby way, and translate between various low and high level HTTP adapters by having standard behaviour-less interim objects.
• It uses dependency injection heavily, so that objects can be reused often and tested simply.
• Internally it does mutation only on object initialization, to minimize potentially invalid states and be somewhat thread-safe without being clever. Public mutation methods return duped modified objects.
• It extends the callback system with a 'pipeline' object that's a collection of before, around, and after callbacks, and wraps it up in an elegant little DSL.

I've about wrapped up the proof of concept, so once I document and push publicly I'll link to it here.