Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99)

> Could you explain why this is an architectural issue?

Ok, I will do that, but please re-read: https://extensiblewebmanifesto.org in the mean time. 

The issue is that the spec defines new primitives, when there are already perfectly good ones we can use. And I quote:

"By focusing on standardizing new low-level capabilities, and building new features in terms of them, we:

 * Contain new security surface area.
 * Allow optimizations in browser engines to focus on the stable core, which affects more APIs as they are added. This leads to better performance with less implementation effort.
 * Allow browser vendors and library authors to iterate on libraries that provide developer-friendly, high-level APIs."

The rest is directly covered by the extensible web manifesto. Again, I don't want to quote the whole thing to you: just please read it, and substitute "PaymentRequest and PaymentResponse" where appropriate. 

> We had several reasons for subsetting the payment request, including privacy (for merchants) 

I don't see how including the PaymentRequest is a privacy issue. And where it is, we should address it. Being lazy and sending back objects is not the right approach. 

> and performance.

You can't be serious 😳!? No one has implemented this yet, so I don't see how we can magically guess at performance characteristic - that sounds like "alternative facts". Premature optimization is the root of all evil. 

And look: if a service worker can handle potentially hundred of network "fetch" events, which have Request object just a complex as those in this API, while also reaching into the Cache database, etc., then a few payment requests are hardly going to be a problem. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/99#issuecomment-274708029