Systems Application WG Face to face -- 31 Oct 2014

<scribe> scribenick: dsr

Wonsuk reviews the agenda for day 2. This is expected to only last half a day.

Application Lifecycle and events

Wonsuk invites Kenneth to summarise current status of work in webapps on Manifest

Kenneth: there is interest from a number of vendors including Mozilla, Google and Microsoft.

Wonsuk: what about scoping?

Kenneth: this is something we want to look at in version 2. This is about how do you scope what is in the app.

Wonsuk: any comments on manifest?

Claes: who are the editors?

Kenneth: Myself, Marcos and Anssi.

Claes: what support is there for content security policies?

Kenneth: we need to solve scoping before we can fully address CSP.

<anssik> can someone go to https://appear.in/sysapps

<anssik> someone who's close to the mic in the meeting room

Wonsuk: Jungkees please give us an update on service worker?

<kenneth_> There is two sides to CSP: Which rules applies to fetching the manifest and its resources (such as icons) and then which CSP to apply to documents launched from the manifest. The latter depends on us figuring out which URL scope applies to the application (ie, where does the app start and where does it end)

<spoussa_> anssik: I am there.

<spoussa_> anssik: nwo what?

Jungkees: very actively being worked on by Google and Mozilla.

Experimental versions are available for developers to try out

Google plan to ship service worker with chrome 40

This is expected to ship very soon!

Microsoft has service worker and manifest in their dashboard for feature iimplementation roadmap

Wonsuk: I previously sent an email to the list on the status of App Lifecycle & events. Kenneth and Anssi already replied. We need to address scoping and the dependency on service worker

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2014Jun/0016.html

Kenneth: the first thing is to decide how service worker integrates with manifest

Maybe this is just an extension of existing specs.

<zolkis> do service workers / hooks inherit the app identity?

<jungkees> zolkis: what do you mean by app identity?

Kenneth: I haven't thought about that

<zolkis> an app has an identity with the store, bound with manifest and permissions

Jungkees: the answer to Zoltan is yes

It is probably bound to the URI of the manifest.

<jungkees> indeed Message API object is bound to a ServiceWorkerRegistration object

Terri: I've been looking at additions to manifest in relation to webappsec. We need to coordinate across sysapps and webappsec on this.

<jungkees> and a ServiceWorkerRegistration object has its scope, which I believe is the thing that you mean the app identity

Wonsuk: so Kenneth we need to think about time for progressing app lifecycle & events?

Kenneth: I am not sure we will need a separate spec for app lifecycle once we address manifest and service worker?

Sakari: so the conclusion is we can drop app lifecycle and rely on web apps?

Wonsuk: we need to investigate further before doing that

Sakari: will webapps address what we need in the future?

Kenneth: I think so

Jungkees: service worker already includes basic lifecycle events, what others do we need?

Kenneth: let's see what web apps does

Dave: Does SysApps have a reasonably complete set of use cases we can use to assess whether the web apps work is sufficient for our needs?

<Zakim> anssik, you wanted to note the spec is an ED thus nothing needs to be retired since it is not on the standards track i.e. not published on w3.org/TR/

Kenneth: some use cases would be nice

<terri> btw, I can't seem to find the link to David Ross's proposal for manifest-related work, but the acronym was EPR and it will show up in the webappsec meeting minutes from earlier this week.

Wonsuk proposes we move on to the next agendum.

re-chartering

<spoussa_> http://lists.w3.org/Archives/Public/public-sysapps/2014May/0017.html

<wonsuk_> ACTION: dave to follow up secure element with crypto and web payment ig [recorded in http://www.w3.org/2014/10/31-sysapps-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

<wonsuk_> ACTION: wonsuk to send an email to web apps about current status, questions(about interesting of the group) of task scheduler api [recorded in http://www.w3.org/2014/10/31-sysapps-minutes.html#action02]

<trackbot> Sorry, but no Tracker is associated with this channel.

<JonathanJ1> yesterday minutes - http://www.w3.org/2014/10/30-sysapps-minutes.html

<anssik> http://lists.w3.org/Archives/Public/public-sysapps/2014May/0017.html

<spoussa_> anssik: we cant hear you

<wonsuk_> Dave: Do we need to think about api related with IoT for new charter?

<wonsuk_> Sakari: It's interesting topic to us, but it's too early so community group is more reasonable to summarize use case and requirement for that

Sakari: I think we should defer new IoT protocols until they have been discussed in CGs

Anssi: do we have more than one implementation today of any of the SysApps deliverables?

Dave: what about additional BLE profiles besides GATT?

Sakari: we could ask the Bluetooth CG if they are willing to address those, and if not we could consider additional Community Groups for those profiles

<anssik> I think we do not satisfy the criteria for WG rechartering with the current deliverables unless we can attract more implementers

<anssik> with only one implementation, we'd be better off incubating the work in a CG

<zolkis> I think we have 2 close enough implementations of the API's - we could work on get them even closer

Dave: if companies have an intention to implement then this is a good sign. We would of course need the implementations to be done before we can exit CR

<anssik> we must define what counts as an implementation

<anssik> +1 to put more effort on UCs and Reqs

<zolkis> my point is, FFOS has a kind of implementation, then specs deviated from that and we have them implemented in Crosswalk. If we can get these close in the future, we'd have a chance for those API's to be back on the standards track.

<anssik> that could help attract new people, help them better understand the problems we're trying to solve

<zolkis> me thinks that basically we do act like a kind of CG for the WebApps WG ;)

<anssik> we need to be able to clearly articulate how SysApps scope differs from that of WebApps and Device APIs

<JonathanJ1> +1 with anssik

Dave: how can we get data on what kinds of APIs developers are most interested in?

Wonsuk: how about talking to the PhoneGap folks?

Sakari: they have daily data on which APIs are used - based upon downloads

<spoussa_> http://plugins.cordova.io/#/

Dave: we could also reach out to the Web Mobile IG who have been looking at requirements

We should be able to learn from both hybrid and native app developers

<zolkis> I think we all agree that when we started sysapps WG, we had a different security/lifecycle model in mind, and the past years went on reasearch and experimenting. Now we have more experience about each API, and IMO we should first decide where do we want to go with the app lifecycle/security model. Then come the use cases for API's and talking about implementations.

Dave: I wonder if Google or Apple might be willing to provide some data?

Wonsuk: we need to survey the APIs being developed, e.g. for Tizen

Dave: for Tizen, how have you determined which APIs are needed?

Wonsuk: we have requests from major application developers, and who have identified gaps in existing APIs
... we have first party and second party developers who are helping us to gather the data.

we break for 20 minutes

Wonsuk: we will resume at 10:50 PST

We resume after coffee

<spoussa_> zolkis: we are talking now..can U hear us?

Dave will summarize by email

Dave will contact spec editors if any questions arise for publication when we already agreed to publish updated public WDs.

<anssik> thanks Wonsuk for chairing, and all participants for good discussions

Wonsuk wraps up the meeting.

- DRAFT -

Systems Application WG Face to face

31 Oct 2014

Attendees

Contents

Application Lifecycle and events

re-chartering

Summary of Action Items

Scribe.perl diagnostic output