W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

[Powerbox] Fine-grained and non-installed providers

From: Kenton Varda <kenton@google.com>
Date: Fri, 26 Feb 2010 17:25:56 -0800
Message-ID: <4112ecad1002261725me460087h866c23b4f87369c1@mail.gmail.com>
To: Tyler Close <tjclose@google.com>, public-device-apis@w3.org
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

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
Received on Saturday, 27 February 2010 01:26:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC