expose to customize and/or add default HTTPotion options
bglusman opened this issue · comments
I have no expertise here, but was curious about choices of HTTPoison vs HTTPotion and came across this article: http://thiagoborg.es/blog/2016/03/20/httpotion-or-httpoison/
Curious about choice of HTTPoison vs Potion (if you had any special reason for choosing one over the other) and whether we should consider passing ibrowse options into Potion requests, and/or allowing config or per request to override these, assuming we stick with Potion? Could also switch to Poison, but I have no particular opinion there, just realized most of the other elastic and HTTP related libs I've been looking at have been using Poison, and wonder if that's because it doesn't require this kind of config for more optimal results.
At @cultureamp we were already using HTTPotion in one of our applications which uses Elastic as a dependency. It made sense to me to only have one HTTP library as a dependency, and so that's what I chose. It's also the one I'm more familiar with.
whether we should consider passing ibrowse options into Potion requests
... for more optimal results.
What would this allow people to do? What options in particular are you thinking about here? What do you mean by "optimal results"?
After actually reading the article, now it makes more sense. I think that Elastic would allow you to pass through these options already, given that the options passed to Elastic.HTTP.post are passed directly to HTTPoison anyway.
For functions that call HTTP functions, I don't know if it would even be possible to pass in ibrowse options from there.
I'm fine with leaving the dependency as HTTPotion for now.
@radar sorry, been meaning to follow up on this... I guess I'd think you'd want to customize it once at the config layer and then always use those settings instead of defaults for all requests? We havent shipped our app using this to production yet and it will probably be fine with whatever settings, but it's definitely possible to pass in ibrowse options from a few places, but I think it HTTPotion is the library we're using it needs to fit into the abstractions... or maybe we can abstract it so it works with either HTTPotion or HTTPoison since the interfaces are very similar? Dunno... can take a crack at if I have time, but I'm not using raw HTTP anywhere, but relying on search and raw_search in a few places, and agree I wouldn't want to specify options there, but thing I should be able to configure options that, if present, get passed in.