Re: Nay vote, no Draft.

On Wed, May 30, 2012 at 8:17 AM, Michiel de Jong <michiel@unhosted.org> wrote:
> On Wed, May 30, 2012 at 4:51 PM, Greg Billock <gbillock@google.com> wrote:
>> This is not missing from the spec. See
>> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#delivery-and-response-api
>>
>> This behavior is currently implemented in the code checked into Chromium.
>>
>> I'm a bit surprised that even a cursory reading of the spec didn't
>> make this more obvious. Is the "Delivery and Response API" header not
>> signaling sufficiently that that part of the spec is about "the
>> service being passed the intent data by the UA, and the service
>> returning data to the UA" ? If there's a clearer way to say that, I'm
>> open to suggestions.
>
> I think the confusion may come from the interaction between the two
> in-browser apps that interact, and the hosted (on some server)
> backends that may or may not be connected to each one. To me, "A web
> page which can handle an Intent is a Service" is a novel way of using
> the word 'service'. I think 'handler' or 'registered web app' or 'web
> app that handles the intent' may be clearer. But i don't speak for the
> OP.

Thanks, this helped me find a regrettable word choice early on -- the
intro should say "applications available on the web" as opposed to
"services available on the web" which isn't the same meaning of
"service" as is used later.

The intro does state pretty clearly that the communication is
client-side only. Perhaps we need some more language to clarify that
any server communication is up to the handler/service page itself?

We've gone through a few different choices of what to call these
things. We ended up with "Service" specifically to try to evoke the
frontend/backend feel -- the service page is acting as the "server" to
the client page.

Received on Wednesday, 30 May 2012 15:36:00 UTC