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

On Fri, Mar 12, 2010 at 11:51 AM, Mark Seaborn <mrs@mythic-beasts.com>wrote:

> On Mon, Mar 8, 2010 at 7:59 PM, Kenton Varda <kenton@google.com> wrote:
> > (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?
>

I can imagine a customer preferring Chinese files but accepting others, if
the customer knew that the user was a native Chinese speaker.

Or, for a more technical example, how about charset?  Say the customer only
accepts UTF-8 text files:

  com.example.File/text/plain;charset=UTF-8


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

The existing MIME type standard has parameters, but not arbitrary parameter
trees.  I think it makes sense to support what MIME supports.

I suppose MIME types do not currently have a notion of hierarchical matching
within each parameter.  I threw that in to cover the "lang" example.  It
seems reasonable to me to expect that other parameters might work this way
but I don't have specific examples in mind.


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

My thought was that the powerbox could order the list based on these q
values.  So, when looking for music files to play, a provider that
explicitly provides music files might show up above one that provides
general files.  This seems more useful that an arbitrary ordering.

Mostly, though, I was trying to emulate the HTTP Accept header, because I
believe it's a good idea to follow existing precedent where it makes sense.