Re: Updates to Payment Apps wiki page

On 11 May 2016 at 13:52, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 9 May 2016 at 17:03, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>
>> Hi Ian and WG,
>>
>> I have made some updates to the payment apps wiki as requested:
>>
>>
>>    - I added a comment about us needing to clarify our scope. I think a
>>    lot of what was in there assumed that the scope was only payment apps that
>>    run in a browser and ignores the possibility of other apps that can still
>>    be interfaced from a browser over the Web.
>>
>> +1 strongly support the inclusion of payments apps that dont run only in
> the browser.
>
> Modern web development allows libraries to be built (eg in javascript)
> that can run in multiple environments
>
> The same workflows (and hopefully code) should be deployable to multiple
> targets
>

Let me expand on the push back against the browser centric nature with some
rationale.

Browser technology has improved over the years but it's been painfully
slow, particularly from an architectural point of view.  So we have the
situation where not only payments, but the whole web is being held back by
browser technology, which has large entry barriers.

The original browser was interactive.  It was a browser editor, meaning the
web was supposed to be an interactive experience.  This all changed with
Mosiac.  Marc Andressen famously decided to focus on multi media delivery
rather than the read write experience.  It was a bold and successful
decision as multi media on the web has become better and better.

But the cost has been that of centralization of the read write aspect from
the browser to the server.  Marc's rationale (acc. to weaving the web) was
that it was too hard to do.  Browsers have been in that mode ever since,
despite the first browser including this functionality.  To be fair once
you can read and write, you probably need to start controlling WHO can read
and write to improve quality which is another layer that wasnt built.
Wikipedia is a good example of such an evolution on the server side.

After Mosaic, Internet Explorer came to dominate the browser, which many
felt were creating a heavy handed approach.  Im not sure I actually agree
with all of that because IE introduced some really nice features for
developers, but push back came in the form of Mozilla (meaning Mosiac
Killer) and then later chrome, as "open source" offerings.  However chrome
now through large market share is arguably in a similar position that IE
was before it.  My personal experience from working with free and open
source software is that the chrome team is operating in as much a heavy
handed way as IE was back before.  So again, we need more diversity, and
browser technology is moving more slowly than what is possible with the
web.  Mozilla still remains a hope for diversity, but all too often they
seem to mirror other centralized players.

This lead to the EFF recently writing the article "save firefox"
(disclaimer: I dont agree with everything in this article)

https://www.eff.org/deeplinks/2016/04/save-firefox

So how does this relate to payments?

Well payments are just a form of data.  If the web was truly a reflection
of it's design, ie a data browser and editor, which is the direction a
large body of W3C standards have aimed in the last 20 years, payments would
be already a natural part of the web.

We are in a strange situation where the work going in in payments outside
the browser is more vital, fluent and exciting than the work in the browser
(which is good work).  But the WG is focusing, and I think this is partly
political, a lot of effort on the browser.

This is leading to the usual situation where work in the community group,
imho, is years ahead of work on the WG.  So it's a challenge to know where
to focus efforts.  Perhaps the CG can become the feeder into the WG,
despite having less process -- normally things dont work that way tho, we
will see.

Id like to see the WG take a more holistic approach that people are asking
for, as well as doing the (imho less interesting) browser centric work, and
make things compatible.  I hope to in my part provide some demos of what
can be done with web technology to help make the conversation practical as
well as theoretical.


>
>
>>    - I added a few definitions to differentiate between browser-based
>>    and web-based apps (per scoping question above).
>>    - I also dropped the hybrid and web-technology apps as I'm not sure
>>    these have any impact on integration with a browser (i.e. an app either
>>    runs in the browser or doesn't which is all that matters from the
>>    perspective of integration with the browser).
>>    - I added the following line to the display text:
>>    "The browser should display matched payment apps in an order that
>>    corresponds with the order of supported payment methods supplied by the
>>    payee"
>>    - I made changes to the advantages and disadvantages of the invoking
>>    and response sections based on discussions with Ian.
>>    (Although I'm still not sure I agree that JavaScript encapsulation
>>    has an advantage of flexibility, I think it's the opposite)
>>    - I corrected the steps in the JavaScript encapsulation approach to
>>    include passing the response to the browser.
>>    - Added a hybrid response approach
>>    - Made some minor changes to the data collection points
>>
>>
>