jimhigson
Feature Request: Migrate interface to match HTTP Fetch Standard
I like Oboe and I've attempted to use it in some of my projects.
A new standard that's looking fairly promising is the Fetch Standard. MDN has a bit of documentation here.
Unlike XMLHttpRequest, it allows you to work with a request and response object by attaching handlers for specific behavior. The interface is, thus, lower-level than XMLHttpRequest and allows for HTTP interceptors and other options.
The Fetch standard is supposed to provide streaming output as Oboe does, but it looks as though the polyfill doesn't support that yet. I'd like to see a version of Oboe that begins to move towards the Fetch standard (in terms of its API and usage) and I'd be willing to work with someone on it. Thoughts?
Sounds interesting @jedd-ahyoung! I'd be willing to help. Maybe what we could do is draft out a proposal of what would need to change.
I'm just getting back to this now, @JuanCaicedo - I'm still pretty interested in this concept. It's been a while since I looked at the Oboe library in depth. I'll have to get up to speed on the framework, but I think I might have some time to pull the source this week.
Fetch is here now, want to look at using it?
The API is quite different so we'd not get much reuse out of the streamingHttp code. I think I'd push the code in streamingHttp down to and then have an xhr and fetch versions. streamingHttp would handle calling them appropriately.
I'm not sure I'd change the API all that much just abstract that from the user and pass the current details we get on to Fetch.
I'll do up a POC and we can go from there.
Maybe it's worth talking about what the benefits of using fetch are. My thought is that because it's closer match to what oboe is trying to do (streaming), the APIs it provide should be more robust and failsafe. I'm also making an assumption that performance should be better, but maybe we should come up with a way of testing that