Ashley Mannix

@dtolnay Thanks! I did actually have a look at your library a little while ago and it was the one I was planning to use. Once I get a few...

I think it's about time to start working on this. The aim is: - Test against the lower level request types by default (not super worthwhile since that'll just be...

Hi @softprops thanks for reaching out! tl;dr We don't accommodate this yet, but I have an idea of how we could reasonably quickly. This is what the `Sender` trait is...

I've got an implementation of this on the `vNext` branch. You can see it [here](https://github.com/elastic-rs/elastic/blob/vNext/src/elastic/examples/pre_send.rs#L45-L47). This will make it in to the next breaking release, which I'm hoping to push...

Hi @MrArnoldPalmer :wave: Even though it's been a _long_ time, the state of the world hasn't actually moved that far since then. I've only just managed to ship a prerelease...

Not having context threaded through the client is starting to hinder the design enough that I think I'll need to sort this out. I think the best approach right now...

I think doing this properly will probably mean refactoring the client internals to focus more on operational types that receive their application state and operational state differently. So rather than...

Hmm, looks like `reqwest` currently doesn't make it easy to determine whether an error was because of a timeout (see https://github.com/seanmonstar/reqwest/issues/229). This will also depend on #290 so we can...

I think this is a good idea :+1: I'm thinking we could map a `Uuid` as something like: ```rust struct DefaultUuidMapping; impl TextMapping for DefaultUuidMapping { fn analyzer() -> Option

@mwilliammyers Sure! We could at least add the necessary impls so you can map a `Uuid` as a keyword. I'll roll this into our current release candidate.