Re: [webpayments] What is the appropriate conversational pattern for the API? (#55)

> So I don't understand the need for an abstract issue about conversational pattern.

The title is misleading. As I said in my follow up there are two issues here, the conversational pattern between the website and the payment app and the conversational pattern between the website and the browser.

I agree that the requirements contribute to the choice of pattern but there are also design constraints that define which patterns are actually implementable. The need to discuss the conversational pattern stems from the need to acknowledge and consider these constraints.

The discussion also identifies which design pattern the requirements are surfacing which should enable us to pick a well-known pattern that addresses these rather than rolling our own.

> The PaymentRequest API does require that you prevent a user from accepting a payment while the web site is given an opportunity to do something that might change the price (such as recalculating shipping costs) but that doesn't require a "frozen" UI

The browser is waiting for a response from the website before it will allow any further processing to be done. This implies that this is a synchronous process (simply using events as the request delivery mechanism doesn't make it asynchronous).  What can the UI do other than freeze and show a "waiting" icon while it waits for the website to respond?

> I think it is essential that they will be made asynchronously. Making synchronous calls that result in I/O is a design anti-pattern that we need to avoid.

I agree but what you are proposing is simply an asynchronous mechanism to acheive a synchronous processing flow. All that does is ensure that nobody locks up the processing during some I/O but the UX is still locked up. 

This is because the use cases that are currently proposed are inter-dependent. The business rules of these interactions define the order in which they are performed and also define what user choices can be made at what stages. The user may be able to pick the shipping method before or after the address but only the payee will know this.

If the choice of shipping method is dependent on the choice of shipping address then there is a synchronous flow of control from the browser to the website, after the user has selected their address, to get the valid methods for that address. The browser UI can't do anything until the website returns a response except ask the user to wait.

> Your assertions are founded on a particular design for payment apps that we wouldn't implement in our platform so this wouldn't be a practical limitation.

Can you elaborate on what aspects of the payment app design won't be implemented by Microsoft? I'd argue that designing any API without understanding the capabilities of the payment app is pointless so we should clarify this first.

> Today the PaymentRequest API proposal has an event driven interface for getting to the final price before allowing delegation to another app. This supports your proposal that "...once we are ready to submit a payment request to the payment app we must have gathered all of the data required for the payment app to process the request as the payment app can't make requests back to the website for more data." But it doesn't require a move away from the conversation pattern that occurs prior to that point.

I agree. I am not proposing that pattern HAS to change. My assertion is that his pattern is less desirable than one which doesn't lock up the UI. If locking up the UI is understood by everyone to be an acceptable limitation we are placing on implementors then that's fine but let's have that conversation.

> the PaymentRequest API proposal has an event driven interface for getting to the final price

I agree with Dave's comments in #41 about the use of events. Requesting information from the website is not an event. It is a synchronous request that requires a response from the caller. As discussed the browser must necessarily stop processing further inputs from the user and wait for a response. This is not the type of interaction that events were designed for.

I don't believe that Promises are the correct mechanism for this either. Perhaps callbacks are a better model?

A variation on the checkout proposal:

```javascript
//Checkout.request takes a callback as its second parameter the signature of all callbacks is the same 
// and includes an object carrying the data provided by the user via the browser.
//Callbacks return an object that is passed to the browser as input to the next request.

var checkout = new Checkout();
checkout.request('shippingAddress', getShippingOptions)
  .request('shippingOption', buildPaymentRequest)
  .request('payment', processPaymentResponse) // Calls the payment request api
  .start();
```

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