- From: Kenton Varda <kenton@google.com>
- Date: Fri, 26 Feb 2010 17:25:56 -0800
- To: Tyler Close <tjclose@google.com>, public-device-apis@w3.org
- Message-ID: <4112ecad1002261725me460087h866c23b4f87369c1@mail.gmail.com>
Hi Tyler, Recapping our lengthy discussion today: 1) We agreed (I think) that the powerbox should not only present "installed" providers, but also any provider advertised in any currently-open tab (including both <link> and <a> tags). This allows the user to quickly form connections between open tabs and to avoid cluttering the installed provider list with providers she does not intend to use frequently. I think this will be a big UI win. It may be worth noting that the UA is responsible for listing the providers *currently* advertised through each tab (at the time the requisition started), which may differ from the list that was available when the provider page was loaded (if the provider is a dynamic webapp). This is obvious when you think about it but would be easy to get wrong. 2) Since (1) means many pages would expose fine-grained providers even when they don't intend for the user to install them, the UA should not prompt the user every time a provider is encountered. Instead, it could do something like display an icon which can be clicked to install the provider, e.g. like some browsers do for RSS feeds. 3) Given that (1) encourages sites to expose providers of transient resources while they are displayed, I think that they may want to be able to prohibit installation of these providers. Otherwise, if the user installs them, they will just become broken links in the provider list, causing confusion. We didn't make any decision on this point. What do you think? 4) In the same discussion, but orthogonal to the above points, I suggested that a provider should be able to specify the set/pattern of MIME types and classes that it is able to serve. The powerbox would then avoid presenting providers which it knows cannot satisfy a particular request. Course-grained providers (e.g. "Google" or "Yahoo") would not use this -- once installed, they would be listed for *all* requests. But, fine-grained providers with narrow services would be able to use it. Since it is specifically when many fine-grained providers are installed that the user would most need such filtering to take effect, this seems to fit together nicely. I agree that "perfect" filtering of providers is a hard problem and mostly outside the scope of this spec, but this seems like something very simple that, while imperfect, would at least be a significant improvement. We didn't have time to discuss this idea in detail. How do you feel about it?
Received on Saturday, 27 February 2010 01:26:46 UTC