Hi All,
I wanted to update everyone on the latest plan for moving forward on the
Streams spec.
For a variety of reasons, there are currently two Streams Specs being worked on
- one in the W3C, and one in the WHATWG. Each of these specs have their
strengths and weaknesses, and were looking at
) to review the latest
> ED or provide the list name(s) and I'll ask them.
>
> -Thanks, ArtB
>
> [ED] <https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm>
>
> On 12/4/13 11:27 AM, ext Feras Moussa wrote:
>> The editors of the Streams API have reached a
The editors of the Streams API have reached a milestone where we feel many of
the major issues that have been identified thus far are now resolved and
incorporated in the editors draft.
The editors draft [1] has been heavily updated and reviewed the past few weeks
to address all concerns raised
Hi Francois,Thanks for the feedback.
> From: francois-xavier.kowal...@hp.com
> To: public-webapps@w3.org
> Date: Wed, 20 Nov 2013 20:30:47 +
> Subject: Comments on version web-apps specs from 2013-10-31
>
> Hello
>
> I have a few comments on:
> https://dvcs.w3.org/hg/streams-api/raw-file/ti
> Streams instantiations somewhere make me think to the structured clone
> algorithm, as I proposed before there should be a method like a
> createStream so you just need to say for a given API that it supports
> this method and you don't have to modify the API except for specific
> cases (xhr,ws,e
Yes, WebSockets was missing - I've gone ahead and updated the spec to include
it.
Thanks for sharing the links, the content is well thought out. In particular,
your diagram does a good job summarizing some of the key consumers and
producers that come to play regarding Streams. I'll review it in
Agreed. Some of the points listed appear to be things already addressed.
Takeshi and I have some feedback on the initial mail, but will wait and provide
thoughts on the proposal instead. Looking forward to seeing it.
> From: tyosh...@google.com
> Date: Fri, 1 No
A few comments inline below -
> From: tyosh...@google.com
> Date: Thu, 31 Oct 2013 13:23:26 +0900
> To: d...@deanlandolt.com
> CC: art.bars...@nokia.com; public-webapps@w3.org
> Subject: Defining generic Stream than considering only bytes (Re: CfC:
> publish W
Takeshi Yoshino wrote:
>> On Thu, Oct 10, 2013 at 11:34 PM, Feras Moussa
>> mailto:feras.mou...@hotmail.com>> wrote:
>>
>> Apologies for the delay, I had broken one of my mail rules and
>> didn't see this initially.
>>
>> Asymeric is correct - there
Apologies for the delay, I had broken one of my mail rules and didn't see this
initially.
Asymeric is correct - there have been a few threads and revisions. A more
up-to-date version is the one Asymeric linked -
http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/stream
Can you please go into a bit more detail? I've read through the thread, and it
mostly focuses on the details of how a Stream is received from XHR and what
behaviors can be expected - it only lightly touches on how you can operate on a
stream after it is received.
The StreamReader by design mimic
Thanks, I've gone ahead and updated the Streams API spec accordingly.
> Date: Thu, 17 Jan 2013 10:46:16 +0100
> From: cyril.concol...@telecom-paristech.fr
> To: public-webapps@w3.org
> Subject: [Streams API] typo
>
> Hi all,
>
> I noticed a typo in the W3C Editor's Draft 25 October 2012 of Strea
Hi all,this is to announce that my affiliation has changed and I no longer work
for Microsoft. I will remain part of the WG as an invited expert, and will
continue on as editor of the Streams API spec.
I've recently made a set of changes to the Streams API[1] and believe the spec
is feature comp
In general we are OK with changing it to the autoRevoke behavior below, but
have some concerns around changing the default behavior.
Changing the default behavior is a breaking change and any apps which expect
the URL to work multiple times will now be broken. In Windows 8, we also
implemented
We agree that the spec text should be updated to more clearly define what
dereference means.
When we were trying to solve this problem, we looked for a simple and
consistent way that a developer can understand what dereferencing is.
What we came up with was the following definition: revoking sh
> -Original Message-
> From: Anne van Kesteren [mailto:ann...@opera.com]
> Sent: Wednesday, March 07, 2012 12:49 AM
> To: Arun Ranganathan; Feras Moussa
> Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson
> Subject: Re: [FileAPI] Deterministic release of Blob prop
> Then let's try this again.
>
> var a = new Image();
> a.onerror = function() { console.log("Oh no, my parent was neutered!"); };
> a.src = URL.createObjectURL(blob); blob.close();
>
> Is that error going to hit?
I documented this in my proposal, but in this case the URI would have
been minted p
> -Original Message-
> From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
> Sent: Tuesday, March 06, 2012 1:32 PM
> To: Kenneth Russell
> Cc: public-webapps@w3.org; Charles Pritchard; Glenn Maynard; Feras
> Moussa; Adrian Bateman; Greg Billock
> Subject:
> From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
> Sent: Tuesday, March 06, 2012 1:27 PM
> To: Feras Moussa
> Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
> Subject: Re: [FileAPI] Deterministic release of Blob proposal
>
> Feras,
>
> Anne confirmed that a new open in onerror or onload /would/ suppress the
> loadend of the first send.
>So we would want a new read/write in onload or onerror to do the same, not
>just those in onabort.
We encountered this same ambiguity in the spec, and we agree with the above.
This is also
in apps
which make extensive use of the APIs.
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Monday, March 05, 2012 12:52 PM
> To: Feras Moussa; Arun Ranganathan; Jonas Sicking
> Cc: public-webapps@w3.org; Adrian Bateman
> Subject: Re: [
At TPAC we discussed the ability to deterministically close blobs with a few
others.
As we've discussed in the createObjectURL thread[1], a Blob may represent
an expensive resource (eg. expensive in terms of memory, battery, or disk
space). At present there is no way for an application to determin
We think the new property bag (objectURLOptions) semantics in the latest
editors draft are very reasonable. We have an implementation of this and
from our experience have found it very widely used internally with app
developers - many leverage it as a way to get an easy to use one-time-use
URL
> -Original Message-
> From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com]
> Sent: Sunday, February 05, 2012 4:50 AM
> To: Feras Moussa
> Cc: Travis Leithead; public-webapps@w3.org
> Subject: Re: StreamBuilder threshold
>
> On 01/26/2012 07:0
stefan.lk.hakans...@ericsson.com]
> Sent: Tuesday, January 17, 2012 12:28 AM
> To: Feras Moussa; Travis Leithead
> Cc: public-webapps@w3.org
> Subject: StreamBuilder threshold
>
> I'm looking at http://html5labs.interoperabilitybridges.com/streamsapi/,
> and specifically at the Str
11Dec/0037.html
> -Original Message-
> From: Anne van Kesteren [mailto:ann...@opera.com]
> Sent: Friday, December 09, 2011 5:15 AM
> To: Wenbo Zhu; Jonas Sicking; Robert O'Callahan; Feras Moussa
> Cc: WebApps WG
> Subject: Re: [XHR] chunked requests
>
> On Th
26 matches
Mail list logo
