Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)

@msporny the proposal is backed by two strong arguments in its favor. If you wish to :-1: the proposal can you address these too?

* There will be benefit to aligning the messaging used in both the HTTP API and JavaScript API.
* The group's efforts are currently focused on the JavaScript API and the design of this API is likely to impact the design of any messages that are exchanged via the API.

Assuming you agree with these statements then my response to the counter proposal is :-1: on the following basis:

> We have enough for a rough-cut at an FPWD right now.

What value is there in publishing a rough-cut API that has had little review from the group and is HIGHLY likely to change? I don't agree with the argument that publishing "sends a message" about the groups position on the API if the group has made a public statement that they plan to publish the API.

> The HTTP API is less contentious than the Browser API (there is no competing spec).

I don't consider the two browser API specs as "competing". They are simply collections of different ideas and approaches to solving the same problem. I expect that the final WG spec will have taken some inspiration from both even if only one is ultimately used as the starting point for a group spec.

It's quite likely that the lack of "contention" is from a lack of interest right now which is exactly the point. If we want to do this properly we should do it when the group can give it due diligence.

> We should send a clear message that a browser API and an HTTP API are equally important to the group.

Are they? You are making that assertion but I am not sure the group agrees. Certainly the lack of review time from the group dedicated to the HTTP API suggests that the browser API is the priority even if both are equally important to publish eventually.

In any case, the proposal is not to devalue or "not do" the HTTP API but to de-prioritize it to save the editors re-doing it when the messaging in the browser API stabilizes.

> Assertions made in the HTTP API may influence the Browser API. We shouldn't merely focus on the browser. There are many other types of HTTP clients out there than just browsers.

I'm not sure this is true either. It would be helpful if you could provide some examples of how this may be the case. It would appear to me that the design considerations for the browser API are far stricter and that building an HTTP API based on the same messages and flows after the fact will be trivial.

If there are user interactions that the browser API comes to depend upon that can't be done in the HTTP API then there is a necessary divergence in the designs anyway because the HTTP API is required to work without user interaction.

I am certainly NOT in favor of compromising the design of the browser API because of requirements of the HTTP API. I don't think the case for them having an identical data-model has been made. While it would be useful for developers it should not restrict the two API's from following appropriate design paths for their unique use cases and requirements.

> We just need a few folks to review the HTTP API and raise issues. At the very worst, we highlight those issues in the spec and push out a FPWD.

Why not simply publish a fresh version of this from the WPCG or WICG? What value is there in pushing this through the WG in a way that implies it's had the necessary attention from the group?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/73#issuecomment-176146814