Re: [Powerbox] Fine-grained and non-installed providers

On Sat, Feb 27, 2010 at 1:25 AM, Kenton Varda <kenton@google.com> wrote:

> 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.
>

Let's call this UI idea "implicit temporary registration".

 * "Implicit" because the user does not have to take any action beyond
visiting a site for the site's providers to be listed in the Powerbox.
 * "Temporary" because the providers are only listed while the providing
site's tab is open.

Firstly, I don't think this would work for <a> links.  If you open a
directory listing of a Tahoe distributed filesystem, for example, it could
contain a large number of <a rel=provider> links for registering each file
or directory as a provider.  The browser/powerbox is not in a good position
to nicely format its own display of this listing: this is best left to the
original page.

I am a little sceptical of the "temporary" aspect of this idea, partly
because I don't think there is any precedent for the operation of one tab
(or window) to depend on an unconnected tab (or window) being open at the
same time.  It reminds me of the gotcha in X Windows' clipboard system,
whereby if the application that owns the clipboard contents exits, the
clipboard contents disappear.  (Though this is more an implementation issue
than a UI issue, the user ends up having to understand that they must not
close the application that owns the clipboard if they want to paste from the
clipboard.)

It seems like this has a discoverability problem:  How would the user
discover that they need to have Gmail open in another tab in order to grant
Facebook access to their Gmail contacts?  Maybe there could be a note in the
Powerbox dialog that suggests opening another tab.  Perhaps you could draw a
sketch of how you would expect the Powerbox dialog to appear (like the
diagram on http://plash.beasts.org/wiki/WebPowerbox)?

The "implicit" aspect seems like it might allow a malicious site to spam the
the user's list of providers, and maybe to spoof legitimate providers.  So
attacker.com might offer a printer provider, in the hope that the user
selects this instead of a real printer.  Maybe you can mitigate the spoofing
problem by listing providers along with the tab they come from in the
Powerbox dialog, but this means you are now expecting users to identify tabs
in a different context from usual.

How would implicit registration handle iframes?  Would you use the <link>
elements from only top-level frames?


> 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.
>

Yes, clearly the browser should not prompt the user just because the user
has visited a page that offers a provider.


> 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.
>

That's a possibility, but it might not work very well on mobile browsers
with limited screen space.  For example, the Android web browser has only a
minimal URL bar.


>
> 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?
>

Can you give some examples of transient providers?  None of the use cases in
my list (in my notes at http://plash.beasts.org/wiki/WebPowerbox) are
transient, such that you would not want to register them with the provider
list.

I see the provider list as being very similar to a bookmarks list, so the
same issues should apply there.  I don't know of any way for a page to say
that its URL is transient and so should not be bookmarked.  (However, I
wouldn't be surprised if there is a <meta> tag for this that no-one uses.)

A bookmarks list or provider list could indicate that an entry was found to
be broken the last time the user tried to use it.  RSS feed readers like
Liferea have a similar feature: Liferea displays a feed with a "broken" icon
if the last attempt to fetch it failed.  A bookmarks/provider list could
even ping its entries periodically as an RSS reader does, but that raises
privacy issues.


> 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.
>

Yes, I have been assuming that providers would be able to declare the
resource types they provide, and the powerbox dialog would display a list of
providers that is filtered by resource type.

I have also been assuming that providers would be "fine-grained", in the
sense that a provider would not offer wildly incompatible types of
resource.  For example, suppose printers are accessible through the
Powerbox.  One provider might be a single printer.  Another provider might
be a printer chooser which offers a choice between hundreds of printers
(e.g. across different offices).  This is fine-grained in the number of
resource types that the providers offer (which is just one: "printer"), but
not in the number of objects that are reachable from any given provider
(which can vary from one to hundreds).

I would not expect a single provider to provide both printers and image
files, because these resources have incompatible interfaces:  one can
receive a file, the other *is* a file.


If the Powerbox is going to provide filtering by resource type, I think
there are two issues we need to deal with:

1) Intersection matching:  Some kinds of resource might not yet have a
single accepted standard interface, so some providers will want to offer
multiple resource type names, e.g. "postscript-printer" and "pdf-printer".
Similarly, a customer web app that can handle either of two resource types
will want to list both type names in its request.  The Powerbox dialog
should list a provider if there is an intersection between the requested and
provided resource types.

2) Subtype matching:  Some resource types are subtypes of others.  For
example, "image file" and "audio file" are both subtypes of "file".  If an
image gallery web app requests an image file, the Powerbox should list both
a take-a-picture camera provider and a local file chooser, but not a sound
recorder.

Ideally the Powerbox's filtering rules should produce the following
outcomes:

  Requested  || Powerbox displays:
  type       || Sound recorder | Camera | Local file chooser
  -----------||----------------|--------|-------------------
  Audio file || yes            | no     | yes
  Image file || no             | yes    | yes
  Any file   || yes            | yes    | yes

We don't want the Powerbox to have a hard-coded list of subtype
relationships (e.g. that "image file" is a subtype of "file") and we don't
want the local file chooser to have to list all the file types it could
possibly provide ("image file", "audio file", etc.).

I think the way to handle this is to encode subtype relationships into type
names.  For example:
 * Local file chooser provides "file/*"
 * Sound recorder provides "file/audio"
 * Camera provides "file/image"
So "file/*" would match "file/image" and vice versa, but "file/image" would
not match "file/audio".  This satisfies the truth table above.

(These type names are for illustration purposes and are not meant to be MIME
types.  A concrete version of this scheme would incorporate MIME types in
some way.)

"file/*" would not match "pdf-printer", so a printer would never be listed
when a file is requested, and vice versa.

Cheers,
Mark