- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 5 Jun 2012 15:01:03 +0200
- To: Adam Barth <w3c@adambarth.com>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, public-sysapps@w3.org
On Jun 4, 2012, at 19:39 , Adam Barth wrote: > On Mon, Jun 4, 2012 at 10:15 AM, Robin Berjon <robin@berjon.com> wrote: >> What you describe fits rather comfortably I believe under the "Application API" in the charter. It can launch apps and talk to them. Making it possible for system apps to handle intents when registered for them is definitely part of the idea behind it. > > Yeah, I figured it would either end up as a mechanism for implementing > the use cases for the Alarm API or the Applications API. In > principle, we should be describing the deliverables in terms of the > use cases they address rather than the mechanisms they use to address > them. Once the group is launched and operating, yes, certainly. But for the charter we have to at least give a broad notion of the mechanisms because it feeds straight into IPR reviews. Erik said: > I mentioned this on another thread, but I also think that it's possible that this will be handled under the execution environment rather than as a specific API. It seems likely that it's deeply tied into application startup, lifetime, etc. As has been mentioned, this underlying capability seems to be needed for a number of disparate APIs (alarm, push, intents, etc.). The important thing is to list all that the group wishes to cover so that we have a defined scope for the group (focusing on IPR). After that, if the group wants to merge deliverables into a single document, split deliverables into more, put everything into one huge monster spec, etc. it's all open — that's just document engineering. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 5 June 2012 13:04:25 UTC