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

On Mon, Mar 8, 2010 at 7:59 PM, Kenton Varda <kenton@google.com> wrote:
> OK, this is now coming together nicely in my head.
> Tweaks:
>
> (1) It should be up to the interface to decide what its specializations
> mean.  An interface which represents a file would probably use MIME
> types, but other interfaces may choose some other taxonomy for their space,
> as long as it is hierarchical.

Right.  The browser/powerbox does not interpret these interface
strings apart from for filtering provider lists, so the meaning of
specialisations is up to the interfaces.

> (2) I think we should consider a trailing "/*" to be redundant.  Otherwise,
> it would be impossible to subdivide an existing category without breaking
> existing customers who omit the "/*" when requesting that category.

This sounds reasonable.  It does mean that the core spec would have to
specify a separator character (such as "/"), but that shouldn't be a
problem.

> (3) There's often more than one sensible way to categorize an object space.
> For example, files might be categorized by type, or by language.  This may
> be a bit of a stretch, but let's say an app wants to accept any file type,
> but only if the content is Chinese.

This example means there would be an app that knows it will not work
on inputs that are not in Chinese, and it believes there will be
providers that know they only provide files that are not in Chinese.
This seems unlikely to me.  Can you think of a more likely example?

My expectation is that the subtype interface matching would be used
when you have a layered interface, such as a generic
transport/container interface that supports multiple contained types.
Some customer apps will operate at the transport/container layer;
others will look at the data in the deeper layers.

Examples of transport/container interfaces would be:

* Get a file using HTTP GET + UMP, given a URL
   - the contained type describes the file contents
* Read a byte stream using HTTP GET + UMP, given a URL
   - the contained type describes the byte stream contents
* Access an SSH server given a hostname + username + private key +
server public key
   - the contained type describes interfaces that are available once
connected to the SSH server

In principle there could be interface types that take two parameters
(e.g. tuple, mapping) but I can't think of any examples that are
plausible at this level.

> How is this expressed?  Probably like:
>   com.example.File/*;lang=cn
> I use a semicolon here because that's what the HTTP "Accept" header uses to
> delimit such parameters.  I think we should use commas to delimit separate
> interfaces which are accepted, again in line with HTTP's "Accept".  So a
> hypothetical audio player that wants Chinese-language audio might be:
>   com.example.AudioInput;lang=cn,com.example.File/audio/*;lang=cn

If we were to take this to its logical conclusion, each parameter
should also be able to contain multiple parameters, and so on
recursively.  So we would have tree-structured interface descriptions,
similar to ML or Haskell types or Prolog term trees, with a matching
rule based on unification.

I'd prefer to avoid this complexity unless we have specific use cases
for it, though.  We could always add more complex matching rules
later, by applying them when both type names start with a special
prefix.

> (4) Like HTTP's "Accept", we should define a universal parameter called "q"
> which can be used to indicate preference for one type over another.  So a
> program which prefers Chinese files but will also accept other files might
> say:
>   com.example.File;lang=cn;q=1,com.example.File;q=0.5

This would be a useful argument for the customer web app to pass to
the provider.  But it doesn't need to be part of the "requested type"
argument that the Powerbox compares with a provider's "provided type",
because these are only used by the Powerbox to filter the provider
list.

Cheers,
Mark

Received on Friday, 12 March 2010 19:51:51 UTC