RE: Discussion on current status and next step of contacts API, Data Store API and TCP and UDP Socket API

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