Re: [w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

FWIW, I'm in support of option 1. 

@adrianhopebailie 
> I am also not convinced that we need a new onpaymentrequest event. Why is inspecting a message and deciding if it's a payment request a bad thing? Any onmessage logic will need to inspect the message to decide what to do next anyway

That would be really confusing. "message" events are for "post message". Having a specific payment event is less confusing, and allows the custom payment stuff to be part of the event itself (and avoids polluting the global scope). 

I see that similar consensus emerged further down the thread, which is good. 

@rsolomakhin 
> , but placing the data in a single file will save a round-trip.

This doesn't matter in a H/2 world. It's premature optimization. 

I'd also like to note that the collaboration across multiple sites to perform a payment feels a bit like "foreign fetch".

I also remain somewhat unconvinced that a web manifest has a big role to play here. I'm still trying to digest the use case, but it doesn't feel right to me at first glance. 
 

-- 
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/33#issuecomment-246244768