Re: Application Launcher (was: Rechartering Device APIs & Policy Working Group)

Bryan,

On Feb 10, 2011, at 04:33 , Bryan Sullivan wrote:
> To be clear, I was referring to the following when I said "I'm not
> sure why you say the ability to detect the registered
> registered/default for a purpose (e.g. music player) and launch it is
> "simply, deeply wrong":
>> The idea that one should be able to do the following is simply, deeply
>> wrong:
>> 
>>  var boomnbox = navigator.apps.gimmeAnAppFor(MUSIC_PLAYING);
>>  // boombox contains "/Applications/iTunes.app"
>>  navigator.apps.runIt(boombox);

That's not really what this code does. This code gets the system path to an arbitrary application and runs it. I could replace "/Applications/iTunes.app" with "rm -Rf ~/*" and it'd work the same.

What you're describing seems to be more along the lines of:

  navigator.apps.launchAppFor(MUSIC_PLAYING);

That's limited to whatever application types are defined in the spec. That can be handled with URI schemes and media types.

> That was an example, and true for things which have a registered URI
> scheme or content-handler status. But it's not true for general app
> launching cases, which is the real gap here. Back in the London
> meeting at the OMTP offices, I agreed that the URI schem approach is
> fine for those type apps (this is why we have that specifically called
> out in the WAC specs). but it is insufficient for the more generic
> cases.

True. But shelling out is still the wrong solution. That's why there's interest in looking at an intents-based model or an introducer approach instead.

> I disagree that this is a death-wish, or that we could not ensure
> appropriate use of the API.

With the approaches being explored, yes I think we can. But with an API that can just run stuff on the system I don't see how.

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 10 February 2011 11:32:48 UTC