Re: Nay vote, no Draft.

i would focus on how this works for unhosted html5 apps (with no
backend). You want them to visualize two open browser tabs on one
device, or even already an "apps launch screen" (which is where i
think we're going) where a number of web apps have been previously
"installed" as registered intent handlers.

If you allow the reader to think of clients and servers, they end up
visualizing http calls, which will confuse the picture.

my 2ct,
Michiel

On Wed, May 30, 2012 at 5:35 PM, Greg Billock <gbillock@google.com> wrote:
> 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:46:46 UTC