> we are committing a cardinal design sin by assuming we know more than we do about what is required based on our own limited knowledge of how our API will be used. I don't think that is true - on the contrary, I'm trying to start small and iterate (this was my first comment to the group at TPAC). We should recognise that v1 of the API won't address all use cases one can imagine but we need to start with something we can implement in a reasonable timeframe, experiment, iterate, and then improve and expand. In the end, on a case by case basis, for v1 people will choose to: 1. Use the API because of its advantages despite some disadvantages 2. Use the API but provide additional data gathering for things the API doesn't yet support 3. Avoid the API until it provides needed functionality. Finding out what people need in (2) and (3) will help us focus on what to do first in v2. I expect to have a proposal for email and phone collection either today or tomorrow pending internal feedback. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/pull/65#issuecomment-215446350
Received on Thursday, 28 April 2016 14:36:24 UTC