- From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
- Date: Sat, 28 Jun 2014 16:46:00 +0200
- To: 'Domenic Denicola' <domenic@domenicdenicola.com>, Wonsuk Lee <wonsuk73@gmail.com>, Marcos Caceres <w3c@marcosc.com>
- CC: "public-sysapps@w3.org" <public-sysapps@w3.org>, Gene Lian <clian@mozilla.com>, Takeshi Yoshino <tyoshino@google.com>
Hi all, Thanks Domenic for the report on the Streams API work! More tangible I can say that the status of the TCP and UDP socket API is that the UDP and TCP client interfaces are based on Streams but I have not yet has time to rewrite the TCP Server interface to be based on Streams. So my tasks for the TCP and UDP Socket API are: * Go through the latest updates of the Streams API and align with those. * Rewrite the TCP Server interface to be based on Streams. I plan to have that fixed prior to the next SysApps f2f, which I believe will be in the beginning of September. BR Claes Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nilsson@sonymobile.com sonymobile.com > -----Original Message----- > From: Domenic Denicola [mailto:domenic@domenicdenicola.com] > Sent: den 27 juni 2014 03:45 > To: Wonsuk Lee; Marcos Caceres > Cc: public-sysapps@w3.org; Gene Lian; Takeshi Yoshino > Subject: RE: Discussion on current status and next step of contacts API, > Data Store API and TCP and UDP Socket API > > From: Wonsuk Lee [mailto:wonsuk73@gmail.com] > > > 2014-06-27 2:48 GMT+09:00 Marcos Caceres <w3c@marcosc.com>: > > >> I haven't kept up with the latest discussion around Streams, > recently. I've cc'ed Domenic Denicola to get status. Implementation > wise, we have no plans in Mozilla to implement streams *right now*. > However, I'm pushing hard to have them added to the platform ASAP... > maybe Q1 2015 or Q2. We don't yet have full ES6 support (e.g., classes, > @@create semantics, object.observe etc.), and I think we want to have > all that in place before we add Streams. > > Glad you asked! > > Since joining Google ~2 weeks ago, I now can work on streams all day, > instead of only in stolen hours after work and on weekends :D. So the > pace has picked up very considerably in the last couple of weeks. > > We are targeting a "v0.9"-esque revision of the spec within the next > week. Right now the major missing piece is helpers for constructing > [transform streams][1], as well as validation that the foundational > work we have done to enable them is sound by creating working demos of > them in action. Once those are in place, I would say the spec will have > all the features needed to ensure that it's a sound model, and would > only be missing some smaller additions that we plan to make > incrementally over time. In short, it would be ready for feedback and > would be a relatively stable base for other specs to depend on. > > Regarding language features: ES6 support is not entirely necessary, > from what I can see. We have a working polyfill (with a growing test > suite!) that wouldn't require anything from ES6 except weak maps (to > create truly private properties) and promises. > > [1]: https://whatwg.github.io/streams/#ts-model > > > In addition it would be great if you can share implementation status > or plan for other browser vendors like chrome, ie, extra. > > On Chrome we have at least one engineer and networking export, Takeshi > (CC'ed), actively helping with the spec and polyfill development, and > investigating how to integrate with other platform APIs. I will let him > speak for exact implementation status and plan, but I think it is > encouraging. > > For IE, I have not heard anything official, but there are definite > positive noises. I will see if I can get some info from them on > status.modern.ie for people to see. > > > It definitely helpful for us to have the visibility for TCP and UDP > Socket API spec! > > The TCP/UDP socket spec is largely based on the streams spec already, > actually! A couple names and terms have changed, but it is a great > example of how to use the streams spec, including adding a few > additional semantics on top of it specific to that protocol.
Received on Saturday, 28 June 2014 14:46:29 UTC