capability restrictions in the runtime strawman

The disabled features in the runtime model strawman:  "The runtime must prevent the application from loading remote subresources using mechanisms that do not have a reasonable offline user experience or programmatic error handling. For example, the runtime must prevent the application from loading remote scripts, workers, iframes, images, and style sheets"  Also disallowed: "form submission"

I understand that's just a straw man, but it may reflect on expectations on what the scope of the WG is.  Our expectation is that these standalone apps can do what browser based web apps can do and more, not less (other than things like history that are dropped because it isn't in a browser).  We'd expect a newspaper app could fetch updated pages, css, images, script and use web workers and submit forms.

>-----Original Message-----
>From: Adam Barth [mailto:w3c@adambarth.com]
>Sent: Tuesday, June 19, 2012 5:24 PM
>To: Jonas Sicking
>Cc: Robin Berjon; Dave Raggett; W3C SysApps
>Subject: Re: poll results
>
>On Tue, Jun 19, 2012 at 4:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Monday, June 18, 2012, Robin Berjon wrote:
>>> On Jun 15, 2012, at 19:38 , Adam Barth wrote:
>>> > On Wed, Jun 13, 2012 at 11:18 AM, Dave Raggett <dsr@w3.org> wrote:
>>> > Only Two Implementors
>>> > ---------------------
>>> >
>>> > Secure Elements API         1   4   2   3   2 Idle API
>>> > 1   2   2   1   2 DNS Resolution API          1   1   2   2   1
>>> > Network Interface API       2   1   2   2   2 Resource Lock API
>>> > 1   1   2   1   2 Serial API                  1   1   2   2   1
>>> > Application API             1   1   2   2   2
>>>
>>> Jonas can confirm for himself, but I think that he made a mistake in
>>> answering the question concerning the Application API, due to the
>>> fuzziness of the API's description. It corresponds to the system
>>> messaging API that he and Mounir have been advocating here.
>>
>> If "Application API" is indeed for things like an app managing it's
>> own lifetime, declaring how/if to be started for incoming messages,
>> managing state to deal with things like being shut down due to system
>> being low on resources, etc, then I'm definitely interested in both
>> speccing and implementing such an API. Don't know if I'd be able to
>> find editing resources, but I'd definitely try to.
>>
>> It's unclear to me how much of stuff like that is an "Application API" vs.
>> how much of it is simply part of the "Execution model" which seems
>> agreed upon by all to be included in Phase 1.
>
>Yeah, that's something the working group will need to sort out.  My sense is that
>at least some of that falls under the execution/runtime model.
>
>If you'd like to get a sense for one possible scope for the runtime model, Erik Kay
>and I have put together a strawman draft:
>
>http://abarth.github.com/sysapps/drafts/runtime.html

>
>Please don't worry about any of the details.  That's all up for discussion once the
>working group starts in ernest.
>
>Adam

Received on Wednesday, 20 June 2012 22:19:44 UTC