On Mon, Mar 9, 2015, at 08:23 PM, Jonas Sicking wrote: > One interesting question to ask here is, would we be interested in > adopting Tizen's API for, for example, SD card access? Or Chrome-app's > API for TCPSocket?
Apologies if you mean these generically without wanting specific discussion. But if it's helpful, I think TCPSocket is an interesting real situation to discuss in this scope because besides it being a dangerous API, there is: 1) A standardization effort is being made at http://www.w3.org/2012/sysapps/tcp-udp-sockets/ (with issues tracked under the github project at https://github.com/sysapps/tcp-udp-sockets). I've been under the impression we intend to convert our implementation to this spec. I've certainly been providing feedback to the spec from experiences developing our email app. 2) An open source shim at https://github.com/whiteout-io/tcp-socket that wraps Chrome's socket API and node.js's socket API to look like (moz)TCPSocket. It will likely be updated to the former standard assuming we follow-through on updating our implementation to conform with the standard. 3) A weird Google Chrome TCP API. Their new API which supersedes their old lower-level-styled API can be found documented at https://developer.chrome.com/apps/sockets_tcp. Integer socket identifiers are used and AFAICT you register listener callbacks for all sockets only. Like for onReceive, the payload is {socketId, data}. Given the existing standardization effort and its arguably superior API, I think we would only want to implement support for the Chrome API as a concerted effort to ease porting of existing Google Chrome extensions or to create a sufficiently-compatible runtime. If we didn't have the standardization effort ongoing, I could see adopting the Google Chrome API and wrapping it for any higher level needs. Andrew _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
