See also: IRC log
https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf
https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf
https://mit.webex.com/mit/j.php?MTID=m41d897ddf2e922b6374c95ac1ee115bf
Proposed: App spec by FTF
1 July available to the WG
adam: +1
<AdrianHB> +1
mahesh: +1
<jnormore> +1
Question: How? :)
AdrianHB: we have a single
document
... if someone wants to propose a conceptual change, I think it
affects a lot of the document
... I have had challenges lately of making time for this
... I hope to do more at least tomorrow and next week
... not sure what availability is for others
... and if we want to figure out a way to divide up work
IJ: I can translate wiki into spec form
adamR: +1
<AdrianHB> +1 too
<jnormore> +1
IJ: My proposal would be to move the content into "spec form"
and then let the rest of you write down what an API looks like
AdrianHB: Then we should use the
issues list
... I think we could put up an idea or question, discuss it,
and then someone can take an action to write a pull request
Goal is: 16 July discuss built up issues
16 June rather
maybe meet 23 June if needed
IJ might try to have an updated draft by 24 June and then people can share with the WG either right away or after more edits
<AdrianHB> +1
Ok with that as next step ("ball is in Ian's court")
<maheshk> +1
AdamR: At risk 16 June
https://github.com/w3c/webpayments/issues/128
<jnormore> Losing you again Ian
IJ: In a payment app spec, what needs to be said?
AdrianHB: How to return a failure
response.
... how does it say "here's a response"
IJ: response codes?
AdrianHB: Right, are there
payment method specific response codes? What about a general
"fail" response?
... we may have some other failuremodeus
... e.g., user cancels
... or "no matching payment method" (browser error)
... or app advertised something it supports but it can't
really
... so we may need a mechanism to enumerate failure modes and
have a way to get data back to the browser
adamR: This is different from what communication mechanism to use
(IJ: Agrees)
Q: Do we only care about apps that work in the browser, or more?
adamr: Isomorphic...even if we just say "in the browser" those apps can call out to the wild (e.g., server-based apps)
AdrianHB: My point in being
specific is that in the future, e.g., we will be dealing with
IOT payments
... "in the browser" requires people to register JS with the
browser.
... but we could do HTTP more easily
... relates also to the question of registration
... I have come around to the notion that some JS will be
necessary
IJ: Seems mostly isomorphic but perhaps not entirely
Adamr: You can use service workers in one case...
IJ: +1 to not having both
AdrianHB: I agree devs have a choice...people can do what they prefer with lightweight shims
mahesh: When will registration
take place?
... what will user experience be?
me 30 mins
scribe: how do users know which browser they are registering with?
AdrianHB: Echoing back - some users have multiple browsers. When they register an app in one browser, they might not find the app when using a different browser
IJ: I expect people will be browsing, will be visiting web sites to register apps in the browser they are using
Mahesh: Another use case is the app is on the phone but the user is not signed up for it.
"Recommended app"
<AdrianHB> this is the enabled vs supported payment methods concept
IJ: I don't know whether "recommended app" will survive in the spec but it's been discussed
AdrianHB: In our spec we will
define an API to let people register a payment app in a given
browser.
... I think that implementers of browsers or platforms will
come up with OTHER (non-standard) ways
... so, e.g., android might allow you to register an app and
android might tell all browsers
... to be clear we are defining the standard way but other
platform-specific ways might exist.
... I understood Zach's comment today to be that the payment
app should not take you on an enrollment process.
... that is different from the merchant being able to recommend
alternative payment apps before you invoke a given payment
app
(IJ agrees with that distinction; thanks)
scribe: I think the latter one is
useful
... especially when the user has no apps installed
Mahesh: Thanks!
- Ian does next draft
- People raise issues in the list
- Next meeting 16 June
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Ian Inferring Scribes: Ian Present: Mahesh Adam Ian Dongwoo AdrianHB Jason WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 02 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/02-apps-minutes.html People with action items:[End of scribe.perl diagnostic output]