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

I think the issue rather is: What are W3C's ambitions?

Since none of the 3-4 vendors you refer to have expressed any
interest in this work, I think that question begs an answer.

Anders

On 2014-11-20 04:25, Manu Sporny wrote:
> 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
>

Received on Thursday, 20 November 2014 06:35:10 UTC