W3C home > Mailing lists > Public > public-sysapps@w3.org > June 2014

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

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>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA302A5A91312C4@seldmbx03.corpusers.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:20 UTC