- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 31 Jul 2014 01:04:18 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYhJQydfdPUvi_hKkmqr3-czRTtOa5LykCXjzEYfjpmrTbQ@mail.gmail.com>
On 30 July 2014 18:15, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > On 2014-07-30 18:09, Melvin Carvalho wrote: > >> >> >> >> On 30 July 2014 17:24, Anders Rundgren <anders.rundgren.net@gmail.com >> <mailto:anders.rundgren.net@gmail.com>> wrote: >> >> On 2014-07-30 14:38, Melvin Carvalho wrote: >> >> >> >> >> On 28 May 2014 15:51, Anders Rundgren < >> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> >> <mailto:anders.rundgren.net@__gmail.com <mailto:anders.rundgren.net@ >> gmail.com>>> wrote: >> >> With this complete lack of clarity, the WebPayments and >> WebID groups >> won't ever leave their Incubation, IG or CG levels. >> >> HTTP 402 to a browser user? Hardly. >> >> So obviously there must be at least two server-actors >> involved, right? >> >> If not, the whole idea is bogus since *internal* operations >> can be built >> as you like and do not need a standards committee for >> guidance. >> >> >> Been thinking this through a bit more, with almost an >> implementation ready. >> >> In the browser scenario the 402 is delivered, but so is human >> readable text. The primary means to continue will be the user taking >> action, by clicking through a wizard that takes them through next steps. >> >> In the scenario of a robot or spider, if they have run out of >> credit they need to obtain a new token, and should be smart enough to know >> how to do this. They keep using this token until that expires, then either >> get a new token, top it up, or send funds via a digital signature. >> >> The workflow for the user is initially non disruptive and does >> not change. But as browsers get smarter either natively, or through >> polyfils etc. The user experience has an upgrade path to make payments >> seamless. >> >> The 402 code is already baked into HTTP, so I'm just working out >> ways to use it. I'm aiming to implement a simple pay wall as a first app., >> but the same technology could be used for pay per view, throttling, shared >> content, protecting sparql endpoints, streaming bandwidth or disk and so on. >> >> >> Hi Melvin, >> >> I understand the motives but would personally not take this route for >> browsers >> which I regards as entirely different to "agents" even if use run >> HTTP. For >> the same reason I don't see HTTP Signatures as a useful browser >> extension either. >> >> Requiring browsers to be smarter is OK, but only if they can perform >> some action >> that the user cannot. If there is some local service that the >> browser can call, >> the server should be able to return the necessary webcode equally >> well. If such >> a service is available or not should be dynamically discoverable. >> >> >> There's no requirement for the browser to change. Every browser that I >> know of, can accept a 402 code today, and can render HTML. That's because, >> it's already standarized as part of HTTP. So from the perspective of the >> browser and the user, it's a non disruptive change. >> > > Right, but what does the 402 add to this particular scenario today? > There's no change to the standard browser experience. The only change is for spiders, robots and AJAX agents than can pass the code on to a handler. > > Anders > > > >> >> IMO, browsers remain the #1 pain-point for the WebPayment and WebID >> communities. >> >> Anders >> >> >> >> >> Anders >> >> >> On 2014-05-28 14:47, Kingsley Idehen wrote: >> >> On 5/28/14 1:27 AM, Anders Rundgren wrote: >> >> The most important thing in a payment scenario are >> the actors and >> their roles. Linked Data in not a panacea. If >> there are only two >> actors, HTML is all you need. >> >> Again, nobody is indicating that Linked Data is a >> panacea. >> >> You need to be able to access, manipulate, and exchange >> data for >> anything to function in our realm of existing. Linked >> Data simply makes >> Data webby or web-like. >> RDF based Linked Data simply ensures the relations that >> constitute the >> Data are human and machine comprehensible. >> >> RDF based Linked Data is a vehicle for encoding and >> decoding >> information, via statements, in the medium provided by >> the Web (an HTTP >> network). >> >> RDF based Linked Data is a kind of Controlled Natural >> Language. >> >> Without Language, we are unable to function. >> >> Links: >> >> [1] http://slidesha.re/QEqLZN -- Natural Language & RDF >> based Linked Data . >> >> [2] http://bit.ly/1c3QeEc -- Language . >> >> >> >> >> >> >> >
Received on Wednesday, 30 July 2014 23:04:47 UTC