DOMRequest vs. DOMFuture

[msporny]

The DOMRequest API does not seem to have a spec yet. The DOMFuture spec exists and seems to have some uptake. We should decide whether or not the return value of the .payment() call should be a DOMFuture or a DOMRequest.

[kumar303]

I like DOMFuture better myself. Also, one thing we ran into with the current DOMRequest is that all it does is tell you if the window was closed. It became hard to work with DOMRequest when we wanted to introduce an intermediate "product catalog" service since there would be multiple callbacks such as windowClosed (the payment flow finished) or paymentCompleted (a valid server postback was received). We started some experiments on that here.

[msporny]

We implemented DOMFuture for the JSON-LD API and it was an... umm... interesting experience. They aren't as baked as we would have liked them to be. The other issue, as you outline above, may be that we might need to include multiple callbacks as options to the .pay()/.payment() method... and stuff like that doesn't tend to play very nicely with DOMFutures. @dlongley probably has more thoughts on this.

[dlongley]

If we use DOMFutures, we would probably just resolve the Future to a different value (have a property in the result that indicated what happened) based on if the payment flow finished or a valid server postback was received -- or whatever other options we might be considering. This would have the same effect as having different callbacks, you would just have to check a property to determine what to call next. My guess would be that this will become the way things are done if DOMFutures gains wide adoption.