Re: Web Intents: Hotswapping

On Tue, Nov 22, 2011 at 2:23 PM, timeless <timeless@gmail.com> wrote:
> On Tue, Nov 22, 2011 at 2:28 PM, Greg Billock <gbillock@google.com> wrote:
>>>> §6 Hotswapping
>
>> I'm understanding 'Hotswapping' to mean that users could select service A
>> one day and service B the next. Yes, I think that's critical.
>
> At the very least.
>
> A pair of use cases that has been raised a lot in DAP are Sensors and Contacts.
>
> Our pitch for them is that for a Client session one could pair with a
> Sensor/Contact-Provider and make repeated requests to/from it without
> triggering additional pairing requests.
>
>> Ergonomics may mean that implementing default settings is the way to go,
>
> right. although my view of defaults is closer to a print dialog where
> your default printer is already selected and you can just click ok, or
> happen to decide to change it. in this model you might not see a list
> of alternatives until you decide you want to change it.

Right. It's a UI challenge. We have some ideas for how to address it
in Chrome (add a "page action" style icon in the omnibox; see [1]),
but it's definitely a puzzle.

>> but perhaps the spec ought to suggest the UA "should" give an easy
>> way to back out of those defaults.
>
> If there aren't session length clients and we see defaults, then yes,
> this is the only should we'd need and we'd need it. If we end up with
> session pairing, then we need more.

My view at present is this should be under the control of the user
agent. The weakness there is that if the client can't depend on a
stable default, then it may present a danger of a "popup storm" for
some use cases. I tend to think that those use cases are better served
by establishing a persistent connection -- part of the semantics of
Web Intents that is really appealing is the user's mediation of the
intent resolution, and too much defaulting weakens that. On the other
hand, it is the UA's job to be a clever agent for the user, and so I
don't think the spec should place too many restrictions on that
behavior. For many use cases, we can probably see what a good solution
would be, but I don't want the spec to end up accidentally walling off
use cases because we don't foresee clever behavior made possible by
the UA in doing defaulting in a slick way.


[1] http://code.google.com/chrome/extensions/pageAction.html

Received on Tuesday, 29 November 2011 18:58:44 UTC