W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: Bjartur's Actual Criticism (finally)

From: Bjartur Thorlacius <svartman95@gmail.com>
Date: Mon, 19 Dec 2011 18:40:41 -0000
To: "Greg Billock" <gbillock@google.com>
Cc: WebIntents <public-web-intents@w3.org>
Message-ID: <op.v6q152aeewg2x1@bxr>
On Mon, 19 Dec 2011 18:05:28 -0000, Greg Billock <gbillock@google.com>  
> There is nothing in the spec forbidding user agents from hooking content  
> and
> providing ways to trigger intents without the direct involvement of
> the client site.
> In fact, I expect this to happen. Extensions should be able to add such  
> hooks
> as well.
I am arguing that as user agents are in a better position to hook content  
and thus the spec should be greatly simplified by removing the client  
interface. Not only should user agents be able to hook content, sites  
should not be encouraged to hide the content and override user agent  
hooking. The specification should at least not imply that it is the  
responsibility of client sites to implement UI for Intents.

> That may be true, and we hope that user agents implement the picker  
> function
> (where the user is asked to select a service) in a non-annoying way. The  
> spec
> is unlikely to mandate anything along these lines directly, though; it
> is a judgment
> call for user agents to make as to how to best perform that function. As
> we've discussed elsewhere, there will probably be a "SHOULD" type  
> suggestion
> here, since to make the ecosystem work, web developers want to have a  
> good
> sense of what happens to users when interacting with these types of  
> controls.
My point was not that pickers could be implemented poorly. My point was  
that users need to be in the loop (i.e. consent), and doing so by  
selecting an action is "better" than by selecting an implementation as  
users may or may not care about the choice of the latter and thus we have  
to assume UAs may guess the choice of service or otherwise automate and  
streamline the process.

> Yes. It sounds like what you have in mind is a wishlist for user agent
> implementation, and that the proposed spec will not forbid any of that  
> behavior,
> and while not mandating it, will probably end up suggesting at least  
> some of it.
> Is that correct?
I wish for UI to be implemented in UAs. I want the spec to specify only  
the interface between UAs and services and leave out all user interface  
implementation details.

What is the use case for the client site interface? Note that while  
technically, as you pointed out, the spec won't forbid sites from not  
using the client site interface, I fear they might. And the only thing I  
can think of using it for is overriding user agents' UIs with whatever UI  
the author has grown accustomed to.

>>>> Users can initiate actions on resources. Users can make two important
>>>> choices: what actions to initiate, and on what resources. Often, but  
>>>> not
>>>> always, they also want to choose the implementation of the action. For
>>>> some actions however, the user most certainly wants the only available
>>>> implementation. On the other hand, initiating an action for which no
>>>> implementation is available is an error.
>>>> The User Agent manages the list of available implementations and media
>>>> types they accept, and thereby the list of valid actions for any type  
>>>> of
>>>> representation of a given resource. Given a resource and types only  
>>>> the
>>>> User Agent is able to present a list of valid actions to the user.
>>>> Sites can offer resources, and they can offer services or  
>>>> implementations
>>>> of
>>>> actions. User Agents can collect these offers and derive what
>>>> implementations can be applied to what resources. Finally, it is the
>>>> user's
>>>> to tell the User Agent what actions to apply on what resources, and  
>>>> where
>>>> necessary, what implementation to use.
Received on Monday, 19 December 2011 18:41:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC