Re: Discussion - Payment APIs: others are thinking about this problem space, too

On 11/17/2014 11:15 AM, David Ezell wrote:
> 1) WebIDL I understand the "handover" issue, but it is an essential 
> work product, and not one that we can or should ignore.

Note that I /did not/ say we should ignore the work product, just that
the WebIDL work product should be able to be implemented using the
current Web Platform. We want to do this to prevent handing over a key
part of the payments architecture to 3-4 very large organizations.

> I understand the point, but consider the following possibility:
> Based on WPAY work (some WG) that produces a WebIDL interface,
> Android developers create a Dalvik VM Interface (Java Classes) that
> are
>> isomorphic< to the WebIDL interface.  Then, any browser port
>> becomes
> trivial, but the semantics of the interface are available for people 
> working in native, hybrid, or pure HTML5 environments.  I could 
> conjecture similarly about iOS or Tizen or any other platform, but 
> who knows.

Yes, I agree. That would be a positive outcome.

The scenario I'm proposing is finding great success without requiring
anyone to produce an Android/iOS/ChromeOS implementation. The less that
we require developers to implement on their particular platform the
better. I think you're saying the same basic thing, but in a slightly
different way, putting more emphasis on "native platform" than the Web
platform.

Given that this is the W3C, if we are forced to pick, I think we should
focus on the Web platform first and native second. Forcing ourselves to
pick one over the other helps us prioritize, which is useful even if we
find out that we can do both easily.

Food for thought, I'm not arguing strongly in either direction yet.

> 2) RESTful WS I agree this one is important, but it tends to address
>  only the "off-platform" use cases.

I'm not sure it's as black and white as that (as Bryan has pointed out).
I'd like most of the technologies that come out of this work to be a
collection of pure JavaScript WebIDL plus open REST APIs. The reason
being that doing so will mean that the technology can be deployed very
quickly and broadly (since the Web platform already has this stuff built
into it).

I think we're in trouble the second we start saying that we're going to
need native browser/Android implementations in order to be successful.

Again, food for thought. We'll need to decide the "best mode" of
deployment of these technologies in the roadmap and these sorts of
things come into play in that particular discussion.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Thursday, 20 November 2014 10:16:02 UTC