- From: Marcos Cáceres <notifications@github.com>
- Date: Mon, 21 Jan 2019 16:55:06 -0800
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 22 January 2019 00:55:28 UTC
@mountainhippo would be great to hear more about the requirements around what needs to be passed. @adrianhopebailie wrote: > I think it would be a mistake to assume we can design anything that "applies to all transactions". Even if that's true now it'll probably not be true for long. I'm mindful that we might not be able to model everything that is needed - but using the `object` IDL type is something our security folks really frown on: even with the JSON serializable check, it still means we need to do extra security checks and data cloning to work with `object` (why, for instance, with Basic Card, we actually cast it to a `BasicCardRequest` dictionary). In short: it's a pain to work with, lacks some useful security assurances, etc. There are a number of ways to deal with the extensibility aspects. If we find a common base, we can use that and extend it using inheritance. But if it's obvious that it won't scale, then yeah... `object` will be the way to go. But we should never start at `object`... `object` is where we land when all else fails. So, I'd say we start with the use cases and requirements for what this thing needs and see how we go. And `object` is always there if we really need it at the end of the day. -- 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/payment-request/issues/817#issuecomment-456235366
Received on Tuesday, 22 January 2019 00:55:28 UTC