System Applications
This is the wiki for discussions on System Applications in support of the System Applications Working Group, see the charter and the public-sysapps@w3.org mailing list.
The aim is to define an run-time environment, security model, and associated APIs for building Web applications that integrate with a host operating system. While this run-time will have substantial overlap with the traditional browser-based run-time environment, it will have some important differences, being focused on Web applications that integrate more strongly with the host platform rather than traditional hosted web sites.
As an example, consider an API to enable access to information in your address book, whether this is stored on your device or in the cloud. For a regular web site, the API should give users explicit control over which information is made available to the web site, rather than giving it free access to everything. A system application API by contrast could be used to create and manage your address book. This requires a higher level of trust in the application code since the API would need to provide free access without the user prompts as required to preserve privacy in the weaker API.
How to get involved
Please subscribe to the public mailing list public-sysapps@w3.org. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the account request form.
In case of further questions, please contact the following:
- Dave Raggett <dsr@w3.org>
Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the W3C Patent Policy.
Editorial process
- Once the WG has reached consensus on which of the proposed drafts to work on, each specification will be given its own repository on the SysApps Organization on Github.
- Each repository will be named after the expected specification shortname. For example, a specification using 'foo' as a W3C shortname should be inside sysapps/foo and be accessible from https://github.com/sysapps/foo/. Having each specification in its own repository provides both editors and interested parties a single palce to monitor changes and issues related to a particular specification.
- On GitHub, please name your spec "index.html"; and, if using Anolis, please include the "index.src.html" file. This allows the specification to be automagically served by GitHub pages.
- All specification text contributions are made via Pull Requests. We ask everyone to do this because every time a commit is made in the repo, and email will be generated. So, to avoid spamming the public mailing list, please fork the repositories into your own account and make pull requests from there.
- Before submitting a pull request, please make sure you format your code. We recommend using [HTML5 Tidy https://github.com/w3c/tidy-html5]. This makes it easier for the integrator and WG members to review your code. For consistency, unformatted HTML code may be rejected.
- At least one person per specification shall have commit access per repository. This person will serve as "integrator", which, reviews changes for editorial issues before any contribution is made into the specification. The integrator makes sure that editorial changes are consistent with the document (e.g., no spelling mistakes, that algorithms make sense, etc.). Major changes should have been discussed previously in the mailing-list in order to ascertain consensus. Thus, the the integrator's role is to make sure that all changes reflect the consensus of the working group.
- Anyone can review and comment on pull requests. Active review from working group members is encouraged.
- Each specification repository will be set up to only have a "gh-pages" branch. This reduces the amount of overhead because contributors directly pull to the correct branch and there is no need to merge from master to gh-pages. In addition, this allows the "unofficial editors' draft" to always be available.
- Unofficial Editorial drafts will be available from the working group area (e.g. http://www.w3.org/2012/sysapps/runtime/). Note the trailing slash is needed. These links are proxied through to http://sysapps.github.io/ using a .htaccess file maintained by the Working Group staff contact.
- Best effort should be made by editors to always direct technical discussions to the W3C public-sysapps mailing list.
- Contributors are welcome to use the "on the fly" edit feature from GitHub to submit changes.
- Trackbot is not going to be used.
Spec writing process FAQ
who assigns labels to issues on GitHub?
Usually the Editor(s) reviewing the bugs assign labels to bugs (e.g., bug, enhancement) - but it's possible for the Chairs to also assign labels.
How do bugs come into the wg agenda and by which priority?
It's really up to the Editors as they are the ones closing the bugs. Bugs that require discussion (or need clarification with the WG) are then brought to the mailing list as needed. Everyone else who is interested in the progression of a spec can op-in to watch a particular repository. Those watching then get notified of bugs and pull requests.
Of course, if work is not progressing on a spec at a good pace, it's up to the Chairs to "crack the whip". Chairs are automatically subscribed to all the repositories as administrators - so they are able to see what is going on and set priorities, labels, milestones, etc. as needed.
For F2F meeting agendas, it is the Editor(s)' responsibility to proposed topics for discussion that will help them complete a spec in timely manner; though any working group member can propose a topic for the agenda.
Is there any mean to allocate deadline for issues (like tracker does for actions)?
Yes. This is done through using GitHub's "milestones" (they are part of the "issues" tab) - it's very handy as you can say that a milestone is due on a particular date and then associate a bunch of bugs with that milestone.
Call for Proposals, Phase 1 (New deadline 1 January 2013)
We are inviting proposals and collecting them on github, see:
Please format your proposals as a W3C working drafts, and use the W3C Document License. For details on how to do this see Adam's email. Once your proposal is on github, please start a new thread on public-sysapps announcing your proposal, ideally with the name of the deliverable in the subject.
Working group participants should feel free to discuss proposals as they are submitted. After November 18th, we'll seek consensus about which of the proposals we want to publish as First Public Working Drafts. Based on our previous discussions, it seems likely that we'll receive multiple proposals for some deliverables. In those cases, the working group might want to combine multiple proposals into a single working draft.
Phase 1
Note: the editor's drafts are linked from the SysApps home page roadmap. The following provides background information including use cases.
Phase 2
Face to Face Meeting
1st F2F Meeting in Madrid (9-11 April 2013) hosted by Telefonica
2nd F2F Meeting in Toronto (27-29 August 2013) hosted by Mozilla
3rd F2F Meeting in Shenzhen (11-12 November 2013) at TPAC 2013
4th F2F Meeting in San Jose (8-9 April 2014) hosted by eBay
For future F2F Meetings
- Jonathan Jeon (ETRI) offer to meet in Seoul
- I'd like to offer three day(or two day) WG meeting and one day event (Korea/Japan/China/W3C Joint Workshop).
- (Option) if it possible, it might be good to co-host with another W3C WG meeting. (e.g WebCrypto API WG or Device API WG)
- I'd like to offer three day(or two day) WG meeting and one day event (Korea/Japan/China/W3C Joint Workshop).
Testing
Support
This work is supported by the European Union's 7th Research Framework Programme (FP7/ 2013-2015) under grant agreement nº611327 - HTML5 Apps.