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

On Wed, Mar 3, 2010 at 1:47 AM, Kenton Varda <kenton@google.com> wrote:

> On Sun, Feb 28, 2010 at 6:09 AM, Mark Seaborn <mseaborn@chromium.org>wrote:
>
>> 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.
>>
>
> This all sounds very interesting, but it's also getting uncomfortably
> complicated for a standard.
>

Actually, the rules I am suggesting are fairly simple and can be implemented
in just a few lines of Python:

def matches_wildcard(ty, possible_wildcard):
    return (possible_wildcard.endswith("*") and
            ty.startswith(possible_wildcard[:-1]))

def types_match(type1, type2):
    return (type1 == type2 or
            matches_wildcard(type1, type2) or
            matches_wildcard(type2, type1))

def typelists_match(typelist1, typelist2):
    return any(types_match(type1, type2)
               for type1 in typelist1.split(";")
               for type2 in typelist2.split(";"))

# Using the short type names above:

print typelists_match("file/audio", "file/*")
# prints True

print typelists_match("file/audio;file/video", "file/audio")
# prints True

print typelists_match("printer/postscript", "file/text")
# prints False



> And how does this extend to specific interfaces?  What happens when we
> replace "file" with "implements the com.example.File interface"?  Audio
> files don't implement a different interface from regular files, unless you
> add a decoder adapter on top.
>

We can just concatenate the Java-style reverse-domain-name interface names
that you suggest with MIME types.  For example:

print typelists_match("com.example.File/*", "com.example.File/audio/mpeg")
# prints True

print typelists_match("com.example.Printer", "com.example.File/audio/*")
# prints False

A generic file chooser provider would offer the type "com.example.File/*",
while a music player might request the type "com.example.File/audio/mpeg".


> It seems like my music player would ask for "An implementation of
> com.example.AudioOutput OR an implementation of com.example.File with MIME
> type 'audio/*'".  How is this expressed?  And how does a provider satisfy
> it?
>

I think you mean AudioInput not AudioOutput.  The music player could request
the type list "com.example.AudioInput;com.example.File/audio/*".  This would
match a provider that offers "com.example.AudioInput" or a provider that
offers "com.example.File/audio/ogg".

print typelists_match(
    "com.example.File/audio/ogg",
    "com.example.AudioInputStream;com.example.File/audio/*")
# prints True

Mark