We have raw sockets support implemented in the Chrome Apps layer[1], for the chrome.socket API[2]. It should be relatively easy to allow both APIs to call the same native code.
Braden [1] https://github.com/MobileChromeApps/chrome-cordova/tree/master/plugins/socket [2] http://developer.chrome.com/apps/socket.html On Tue, Apr 9, 2013 at 11:35 AM, Filip Maj <[email protected]> wrote: > Day one of three days of meetings. I'll summarize what was discussed and > how Cordova fits in. As always if anyone here has anything they would like > me to raise specifically with the group let me know. > > For reference the agenda is here: > http://www.w3.org/wiki/System_Applications:_1st_F2F_Meeting_Agenda > > General inquiries about Cordova included: > - Wong Suk (co chair of the group, works for Samsung) very interested in > using Cordova as a prototyping/feedback platform for W3C apis. I was very > happy to hear this! > - Also overheard some folk from Samsung say, essentially, Bada is done, > but I am paraphrasing here. > - Got beat up a bit about Cordova's lack of participation in the W3C. > Moving > forward I'll try be more diligent about bringing our community's feedback > into the standards discussion. Good point made to me was that even if a > draft has changed and the feedback may not be applicable to a current > draft of an API (I.e. Contacts), providing feedback is still useful (were > the standards decisions validated or not?). > > Specific topics covered, and my take on how they relate to Cordova: > > - Main focus: runtime and security model for packaged and hosted web > applications [1]. > - Cordova currently uses config.xml. There was interest in the group > about what Cordova's future w.r.t. To describing app metadata was. My > answer was: eventually I see us moving to the SysApps application manifest > [2]. > - Interesting and relevant to our interests: app: URI [3]. A nice URI > abstraction for referencing in-package assets. Solves some of the in-app > File URL issues that have come up in the past for Cordova. Between app: > URIs and PERSISTENT / TEMPORARY LocalFileSystem references, I think we've > got all file system access use cases covered. > - There is a document in the works covering security use cases and > trying to draft requirements/policies around the runtime's security model > [4]. > - Secondary foci: alarm and raw socket APIs. Not sure if that¹s super > relevant to our current work, but hey, it's there. Will do my best to put > more focus on APIs that are asked about more often by our community in the > coming days (web capabilities, push notification). > - Alarm api draft [5]. > - Raw sockets api draft [6]. > > [1] http://runtime.sysapps.org/ > [2] http://runtime.sysapps.org/#application-manifest > [3] http://appuri.sysapps.org/ > [4] http://notes.sysapps.org/security-requirements/ > [5] http://sysapps.github.io/sysapps/proposals/alarm/Overview.html > [6] http://raw-sockets.sysapps.org/ > >
