Re: Art steps down - thank you for everything

2016-02-01 Thread Takeshi Yoshino
Thank you Art! Takeshi On Mon, Feb 1, 2016 at 12:39 AM, Tobie Langel wrote: > So long, Art, and thanks for all the fish. > > --tobie > > On Thu, 28 Jan 2016, at 16:45, Chaals McCathie Nevile wrote: > > Hi folks, > > > > as you may have noticed, Art has resigned as a

Re: [charter] What is the plan for Streams API?

2015-08-05 Thread Takeshi Yoshino
+domenic We've recently finished the ReadableStream part of the spec and experimenting integration with the Fetch API. Most of the spec is still unstable. I don't have bandwidth to maintain W3C version of the spec even briefly currently... Takeshi On Tue, Aug 4, 2015 at 11:13 PM, Arthur Barstow

Re: Allow custom headers (Websocket API)

2015-02-06 Thread Takeshi Yoshino
Usually, - IETF HyBi ML http://www.ietf.org/mail-archive/web/hybi/current/maillist.html for protocol stuff - Here or WHATWG ML https://lists.w3.org/Archives/Public/public-whatwg-archive/ for API stuff On Thu, Feb 5, 2015 at 11:07 PM, Michiel De Mey de.mey.mich...@gmail.com wrote: Standardizing

Re: Allow custom headers (Websocket API)

2015-02-05 Thread Takeshi Yoshino
On Thu, Feb 5, 2015 at 10:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: A Websocket connection is established by making a HTTP Upgrade request, and the protocol is HTTP unless and until the connection is upgraded.

Re: Allow custom headers (Websocket API)

2015-02-05 Thread Takeshi Yoshino
On Thu, Feb 5, 2015 at 10:41 PM, Florian Bösch pya...@gmail.com wrote: On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino tyosh...@google.com wrote: To prevent WebSocket from being abused to attack existing HTTP servers from malicious non-simple cross-origin requests, we need to have WebSocket

Re: Allow custom headers (Websocket API)

2015-02-05 Thread Takeshi Yoshino
To prevent WebSocket from being abused to attack existing HTTP servers from malicious non-simple cross-origin requests, we need to have WebSocket clients to do some preflight to verify that the server is not an HTTP server that don't understand CORS. We could do e.g. when a custom header is

Re: Allow custom headers (Websocket API)

2015-02-05 Thread Takeshi Yoshino
request's response tainting to CORS. The result of performing an HTTP fetch using request with the CORS flag and CORS preflight flag set. Authorization header is not a simple header. On Thu, Feb 5, 2015 at 10:48 PM, Florian Bösch pya...@gmail.com wrote: On Thu, Feb 5, 2015 at 2:44 PM, Takeshi

Re: =[xhr]

2014-11-24 Thread Takeshi Yoshino
On Wed, Nov 19, 2014 at 1:45 AM, Domenic Denicola d...@domenic.me wrote: From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes

Re: =[xhr]

2014-11-18 Thread Takeshi Yoshino
How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? Takeshi On Tue, Nov 18, 2014 at 7:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote: I still think

Re: =[xhr]

2014-11-17 Thread Takeshi Yoshino
We're adding Streams API https://streams.spec.whatwg.org/ based response body receiving feature to the Fetch API See - https://github.com/slightlyoff/ServiceWorker/issues/452 - https://github.com/yutakahirano/fetch-with-streams Similarly, using WritableStream + Fetch API, we could allow for

Re: =[xhr]

2014-11-17 Thread Takeshi Yoshino
On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give a potential hostile piece of script that much

Re: =[xhr]

2014-11-17 Thread Takeshi Yoshino
On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola d...@domenic.me wrote: From: Takeshi Yoshino [mailto:tyosh...@google.com] On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we

Re: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

2014-10-24 Thread Takeshi Yoshino
On Fri, Oct 24, 2014 at 8:24 PM, Arthur Barstow art.bars...@gmail.com wrote: On 10/23/14 1:26 PM, Domenic Denicola wrote: From: Arthur Barstow [mailto:art.bars...@gmail.com] I think recent threads about Streams provided some useful information about the status and plans for Streams. I also

Re: [streams-api] Seeking status of the Streams API spec

2014-10-22 Thread Takeshi Yoshino
Hi Arthur, OK. Since I hurried, there're some odd texts left. Fixed: https://dvcs.w3.org/hg/streams-api/rev/891635210233 On Tue, Oct 21, 2014 at 10:53 PM, Arthur Barstow art.bars...@gmail.com wrote: On 10/14/14 11:06 PM, Takeshi Yoshino wrote: Not to confuse people, too late but I replaced

Re: [streams-api] Seeking status of the Streams API spec

2014-10-14 Thread Takeshi Yoshino
; Takeshi Yoshino; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.org Subject: RE: [streams-api] Seeking status of the Streams API spec Where is the latest Streams spec? https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm doesn't have much about WritableStreams

Re: File API: reading a Blob

2014-09-17 Thread Takeshi Yoshino
/09/2014 08:36, Takeshi Yoshino a écrit : On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte vitteayme...@gmail.com wrote: Does your experimentation pipe the XHR stream to MSE? Obviously that should be the target for yt, this would be a first real application of the Streams API. It's

Re: File API: reading a Blob

2014-09-11 Thread Takeshi Yoshino
should be the behavior in term of back pressure for things coming from outside of the browser (xhr, websockets, webrtc, etc , not specified as far as I know) and for things going on inside the browser (already specified) Le 08/09/2014 06:58, Takeshi Yoshino a écrit : On Thu, Sep 4, 2014 at 7:02

Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?

2014-08-14 Thread Takeshi Yoshino
figuring out very basic issues and focus on the Fetch. Takeshi On Thu, Aug 14, 2014 at 4:03 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 14, 2014 at 6:20 AM, Takeshi Yoshino tyosh...@google.com wrote: We're implementing Streams API and integration of it and XHR experimentally

Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?

2014-08-14 Thread Takeshi Yoshino
On Thu, Aug 14, 2014 at 4:29 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 14, 2014 at 9:19 AM, Takeshi Yoshino tyosh...@google.com wrote: We'd like to continue prototyping in Blink anyway to provide feedback to the spec as browser developer's point of view, but if we're sure

[Streams API] Add load-using-streams functionality to XHR or only to Fetch API?

2014-08-13 Thread Takeshi Yoshino
We're implementing Streams API [1] and integration of it and XHR [2] experimentally in Blink [3][4]. Anne suggested that we look into adding new fetch-layer features to the Fetch API [5][6] rather than XHR in Blink mailing list (blink-dev) [6]. There's a concern if we can ship the Fetch API to

Re: XMLHttpRequest: uppercasing method names

2014-08-12 Thread Takeshi Yoshino
On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell bkard...@gmail.com wrote: If there's no really good reason to change it, least change is better IMO All I can think of is that it would be somewhat more consistent to

Re: XMLHttpRequest: uppercasing method names

2014-08-12 Thread Takeshi Yoshino
On Wed, Aug 13, 2014 at 12:15 AM, Brian Kardell bkard...@gmail.com wrote: On Aug 12, 2014 11:12 AM, Takeshi Yoshino tyosh...@google.com wrote: On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell bkard...@gmail.com

Re: XMLHttpRequest: uppercasing method names

2014-08-12 Thread Takeshi Yoshino
On Wed, Aug 13, 2014 at 1:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 12, 2014 at 5:15 PM, Brian Kardell bkard...@gmail.com wrote: fetch should explain magic in XMLHttpRequest et all.. I don't see how it could differ in the way you are suggesting and match Well fetch()

Re: Fetch API

2014-06-04 Thread Takeshi Yoshino
On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 29, 2014 at 4:25 PM, Takeshi Yoshino tyosh...@google.com wrote: http://fetch.spec.whatwg.org/#dom-request Add steps to set client and context? That happens as part of the restricted copy. However

Re: Fetch API

2014-06-04 Thread Takeshi Yoshino
For XHR.send(), we've finally chosen to accept only ArrayBufferView. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0141.html Do we want to do the same for FetchBody body of RequestInit?

Re: Fetch API

2014-05-29 Thread Takeshi Yoshino
http://fetch.spec.whatwg.org/#dom-request Add steps to set client and context? http://fetch.spec.whatwg.org/#cors-preflight-fetch-0 Add steps to set client and context? http://fetch.spec.whatwg.org/#concept-legacy-fetch http://fetch.spec.whatwg.org/#concept-legacy-potentially-cors-enabled-fetch

Re: [promises] Guidance on the usage of promises for API developers

2014-01-29 Thread Takeshi Yoshino
New texts look nice. Two comments... - XMLHttpRequest.send() is a good example, but as we go through multiple states and invokes onreadystatechange multiple times, I prefer not just quoting onreadystatechange but point the one-and-done aspect of XHR by using phrase like which triggers

Re: [promises] Guidance on the usage of promises for API developers

2014-01-14 Thread Takeshi Yoshino
Nice writing! Both the shorthand phrases and guidance look very useful for writing Promise based specs. I have only one comment on this section. https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md#maintain-a-normal-control-flow I agree with

Re: [promises] Guidance on the usage of promises for API developers

2014-01-14 Thread Takeshi Yoshino
To address, jgraham's point, let's go back to just use Run ... style phrasing. I agree that we shouldn't mislead readers that task queuing is always necessary. Moreover, I think algorithm may be allowed to be done either synchronously or asynchronously for some cases. Maybe we could add possibly

Re: Request for feedback: Streams API

2013-12-17 Thread Takeshi Yoshino
Hi, Implementation of back pressure is important for handling large data stably. The Streams need to ask the consumer code to notify it when it can consume more data. Triggering this signal by method invocation is one of possible options. Promises fit this well. To address smaug___'s concern, we

Re: Request for feedback: Streams API

2013-12-09 Thread Takeshi Yoshino
Thanks. ByteStream is already partially implemented in Blink/Chromium. As one of implementors, I'll continue prototyping and share issues here. I haven't got time for, but writing some polyfill might be also good thing to do. Takeshi On Thu, Dec 5, 2013 at 2:38 AM, Kenneth Russell

Re: Comments on version web-apps specs from 2013-10-31

2013-12-09 Thread Takeshi Yoshino
Thanks for feedback. On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa feras.mou...@hotmail.comwrote: 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

Re: CfC: publish Proposed Recommendation of Progress Events; deadline November 25

2013-11-18 Thread Takeshi Yoshino
two minor comments - add semicolons to lines of the example code in the introduction section? - 2nd paragraph in the conformance section, quote must?

Re: Thoughts behind the Streams API ED

2013-11-12 Thread Takeshi Yoshino
On Tue, Nov 12, 2013 at 5:23 PM, Aymeric Vitte vitteayme...@gmail.comwrote: No, see my previous reply, unless I am proven incorrect, I still think we should have: - pause/unpause - stop/(implicit resume) Regards, Aymeric Le 11/11/2013 22:06, Takeshi Yoshino a écrit : Aymeric, Re

Re: Thoughts behind the Streams API ED

2013-11-12 Thread Takeshi Yoshino
On Tue, Nov 12, 2013 at 5:20 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Takeshi, See discussion here too: https://github.com/whatwg/streams/issues/33 The problem with stop again is that I need to handle myself the clone operations, the advantage of stop-eof is: - clone the operation

Re: Thoughts behind the Streams API ED

2013-11-11 Thread Takeshi Yoshino
Aymeric, Re: pause()/resume(), I've moved flow control functionality for non-exact read() method to a separate attribute pullAmount [1] [2]. pullAmount limits the max size of data to be read by read() method. Currently the pipe() method is specified not to respect pullAmount but we can choose to

Re: Thoughts behind the Streams API ED

2013-11-08 Thread Takeshi Yoshino
On Fri, Nov 8, 2013 at 5:38 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Please see here https://github.com/whatwg/streams/issues/33, I realized that this would apply to operations like textDecoder too without the need of an explicit stream option, so that's no more WebCrypto only related.

Re: Thoughts behind the Streams API ED

2013-11-08 Thread Takeshi Yoshino
Sorry. I've cut the input at wrong position. textDecoderStream.write(arraybuffer of 0xd0 0xa0 0xd0 0xbe 0xd1 0x81 0xd1); textDecoderStream.stop(); textDecoderStream.write(arraybuffer of 0x81 0xd0 0xb8 0xd1 0x8f)

Re: Thoughts behind the Streams API ED

2013-11-08 Thread Takeshi Yoshino
On Fri, Nov 8, 2013 at 8:54 PM, Aymeric Vitte vitteayme...@gmail.comwrote: I would expect Poc (stop, keep 0xd1 for the next data) and сия It can be seen a bit different indeed, while with crypto you expect the finalization of the operation since the begining (but only by computing the latest

Re: Thoughts behind the Streams API ED

2013-11-07 Thread Takeshi Yoshino
On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte vitteayme...@gmail.comwrote: stop/resume: Indeed as I mentioned this is related to WebCrypto Issue22 but I don't think this is a unique case. Issue22 was closed because of lack of proposals to solve it, apparently I was the only one to care

Re: Thoughts behind the Streams API ED

2013-11-07 Thread Takeshi Yoshino
On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Le 07/11/2013 10:21, Takeshi Yoshino a écrit : On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte vitteayme...@gmail.comwrote: stop/resume: Indeed as I mentioned this is related to WebCrypto Issue22 but I don't think

Re: Thoughts behind the Streams API ED

2013-11-06 Thread Takeshi Yoshino
On Wed, Nov 6, 2013 at 7:33 PM, Aymeric Vitte vitteayme...@gmail.comwrote: I have seen the different bugs too, some comments: - maybe I have missed some explaination or some obvious thing but I don't understand very well right now the difference/use between readable/writablebytestream and

Re: Thoughts behind the Streams API ED

2013-11-05 Thread Takeshi Yoshino
FYI, I added a branch named Preview version into which suggestions are incorporated aggressively to see how the API surface would be change. https://dvcs.w3.org/hg/streams-api/raw-file/tip/preview.html Please take a look if you're interested in. For stabler version edited after having discussion,

Thoughts behind the Streams API ED

2013-11-04 Thread Takeshi Yoshino
I'd like to summarize my ideas behind this API surface since the overlap thread is too long. We'll put these into bug entries soon. Feedback on Overlap thread, especially Issac's exhaustive list of considerations and conversation with Aymeric were very helpful. In reply to his mail, I drafted my

Re: Thoughts behind the Streams API ED

2013-11-04 Thread Takeshi Yoshino
On Tue, Nov 5, 2013 at 2:11 AM, Takeshi Yoshino tyosh...@google.com wrote: Feedback on Overlap thread, especially Issac's exhaustive list of considerations Deleted citation by mistake. [1] is the Issac's post. [1] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0355.html

Re: publish WD of Streams API; deadline Nov 3

2013-10-31 Thread Takeshi Yoshino
OK. There seems to be some disconnect, but I'm fine with waiting for Domenic's proposal first. Takeshi On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I have concrete suggestions

Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)

2013-10-31 Thread Takeshi Yoshino
On Thu, Oct 31, 2013 at 4:48 PM, François REMY francois.remy@outlook.com wrote: Since JavaScript does not provide a way to check if an object implements an interface, there should probably exist a way to check that from the API, like: Basically it should be sufficient if each API can

Re: Overlap between StreamReader and FileReader

2013-10-30 Thread Takeshi Yoshino
impossible for a js app to do a precise flow control, and for existing APIs like WebSockets it's not easy to control the flow and avoid in some situations to overload the UA. Regards, Aymeric Le 21/10/2013 13:14, Takeshi Yoshino a écrit : Sorry for blank of ~2 weeks. On Fri, Oct 4, 2013 at 5:57

Re: Overlap between StreamReader and FileReader

2013-10-30 Thread Takeshi Yoshino
On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino tyosh...@google.comwrote: On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte vitteayme...@gmail.comwrote: - pause: pause the stream, do not send eof Sorry, what will be paused? Output? http://lists.w3.org/Archives/Public/public-webrtc/2013Oct

Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)

2013-10-30 Thread Takeshi Yoshino
Hi François On Thu, Oct 31, 2013 at 6:16 AM, François REMY francois.remy@outlook.com wrote: - Streams should exist in at least two fashions: InputStream and OutputStream. Both of them serve different purposes and, while some stream may actually be both, this remains an exceptional

Defining generic Stream than considering only bytes (Re: CfC: publish WD of Streams API; deadline Nov 3)

2013-10-30 Thread Takeshi Yoshino
Hi Dean, On Thu, Oct 31, 2013 at 11:30 AM, Dean Landolt d...@deanlandolt.com wrote: I really like this general concepts of this proposal, but I'm confused by what seems like an unnecessary limiting assumption: why assume all streams are byte streams? This is a mistake node recently made in

Re: Overlap between StreamReader and FileReader

2013-10-21 Thread Takeshi Yoshino
Sorry for blank of ~2 weeks. On Fri, Oct 4, 2013 at 5:57 PM, Aymeric Vitte vitteayme...@gmail.comwrote: I am still not very familiar with promises, but if I take your preceeding example: var sourceStream = xhr.response; var resultStream = new Stream(); var fileWritingPromise =

Re: [streams-api] Seeking status and plans

2013-10-11 Thread Takeshi Yoshino
On Thu, Oct 10, 2013 at 11:34 PM, Feras Moussa feras.mou...@hotmail.comwrote: 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 -

Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-10-04 Thread Takeshi Yoshino
On Fri, Oct 4, 2013 at 8:46 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino tyosh...@google.com wrote: On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren ann...@annevk.nl wrote: This is the end user terminate, correct? Yes. So, this includes

Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-10-04 Thread Takeshi Yoshino
On Sat, Oct 5, 2013 at 1:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino tyosh...@google.com wrote: Sorry. I included network by mistake. I wanted to understand the abort error well. Q: cancel by abort() is abort error? It's

Re: Overlap between StreamReader and FileReader

2013-10-03 Thread Takeshi Yoshino
Formatted and published my latest proposal at github after incorporating Aymeric's multi-dest idea. http://htmlpreview.github.io/?https://github.com/tyoshino/stream/blob/master/streams.html On Sat, Sep 28, 2013 at 11:45 AM, Kenneth Russell k...@google.com wrote: This looks nice. It looks like

Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-10-02 Thread Takeshi Yoshino
Sorry for the delay. On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino tyosh...@google.com wrote: In the spec, we have three cancels - cancel an instance of fetch algorithm - cancel network activity

Re: Overlap between StreamReader and FileReader

2013-09-26 Thread Takeshi Yoshino
On Thu, Sep 26, 2013 at 6:36 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Looks good, comments/questions : - what's the use of readEncoding? Overriding charset specified in .type for read op. It's weird but we can ask an app to overwrite .type instead. - StreamReadType: add

Re: Overlap between StreamReader and FileReader

2013-09-25 Thread Takeshi Yoshino
On Wed, Sep 25, 2013 at 10:55 PM, Aymeric Vitte vitteayme...@gmail.comwrote: My understanding is that the flow control APIs like mine are intended to be used by JS code implementing some converter, consumer, etc. while built-in stuff like WebCrypt would be evolved to accept Stream directly

Re: Overlap between StreamReader and FileReader

2013-09-25 Thread Takeshi Yoshino
As we don't see any strong demand for flow control and sync read functionality, I've revised the proposal. Though we can separate state/error signaling from Stream and keep them done by each API (e.g. XHR) as Aymeric said, EoF signal still needs to be conveyed through Stream. enum

Re: Overlap between StreamReader and FileReader

2013-09-24 Thread Takeshi Yoshino
On Wed, Sep 25, 2013 at 12:41 AM, Aymeric Vitte vitteayme...@gmail.comwrote: Did you see http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0593.html ? Yes. This example seems to be showing how to connect only producer/consumer APIs which support Stream. Right? In such a case,

Re: Overlap between StreamReader and FileReader

2013-09-20 Thread Takeshi Yoshino
On Sat, Sep 14, 2013 at 12:03 AM, Aymeric Vitte vitteayme...@gmail.comwrote: I take this example to understand if this could be better with a built-in Stream flow control, if so, after you have defined the right parameters (if possible) for the streams flow control, you could process delta

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino
On Fri, Sep 13, 2013 at 6:08 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Now you want a stream interface so you can code some js like mspack on top of it. I am still missing a part of the puzzle or how to use it: as you mention the stream is coming from somewhere (File, indexedDB,

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino
Since I joined discussion recently, I don't know the original idea behind the Stream+XHR integration approach (response returns Stream object) as in current Streams API spec. But one advantage of it I come up with is that we can keep change to those producer APIs small. If we decide to add methods

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino
On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Le 13/09/2013 14:23, Takeshi Yoshino a écrit : Do you mean that those data producer APIs should be changed to provide read-by-delta-data, and manipulation of data by js code should happen there instead

Re: Overlap between StreamReader and FileReader

2013-09-12 Thread Takeshi Yoshino
On Thu, Sep 12, 2013 at 10:58 PM, Aymeric Vitte vitteayme...@gmail.comwrote: Apparently we are not talking about the same thing, while I am thinking to a high level interface your interface is taking care of the underlying level. How much low level stuff to expose would basically affect

Re: Overlap between StreamReader and FileReader

2013-09-12 Thread Takeshi Yoshino
On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte vitteayme...@gmail.comwrote: Isaac said too So, just to be clear, I'm **not** suggesting that browser streams copy Node streams verbatim.. I know. I wanted to kick the discussion which was stopped for 2 weeks. Unless you want to do node

Re: Overlap between StreamReader and FileReader

2013-09-11 Thread Takeshi Yoshino
Here's my all-in-one strawman proposal including some new stuff for flow control. Yes, it's too big, but may be useful for glancing what features are requested. enum StreamReadType { , arraybuffer, text }; [Constructor(optional DOMString mime, optional [Clamp] long long

Re: Overlap between StreamReader and FileReader

2013-09-11 Thread Takeshi Yoshino
I forgot to add an attribute to specify the max size of backing store. Maybe it should be added to the constructor. On Wed, Sep 11, 2013 at 11:24 PM, Takeshi Yoshino tyosh...@google.comwrote: any peek(optional [Clamp] long long size, optional [Clamp] long long offset); peek with offset

Re: Overlap between StreamReader and FileReader

2013-09-10 Thread Takeshi Yoshino
On Fri, Aug 23, 2013 at 2:41 AM, Isaac Schlueter i...@izs.me wrote: 1. Drop the read n bytes part of the API entirely. It is hard to do I'm ok with that. But then, instead we need to evolve ArrayBuffer to have powerful concat/slice functionality for performance. Re: slicing, we can just make

Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

2013-09-03 Thread Takeshi Yoshino
On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino tyosh...@google.com wrote: Change on 2010/09/13 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h reversed

Re: Overlap between StreamReader and FileReader

2013-05-18 Thread Takeshi Yoshino
On Sat, May 18, 2013 at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: For File reading I would now instead do something like partial interface Blob { AbortableProgressFutureArrayBuffer readBinary(BlobReadParams); AbortableProgressFutureDOMString readText(BlobReadTextParams); Stream

Re: Overlap between StreamReader and FileReader

2013-05-18 Thread Takeshi Yoshino
On Sat, May 18, 2013 at 1:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, May 17, 2013 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote: For Stream reading, I think I would do something like the following: interface Stream { AbortableProgressFutureArrayBuffer readBinary(optional

Re: Overlap between StreamReader and FileReader

2013-05-17 Thread Takeshi Yoshino
Sorry, I just took over this work and so was misunderstanding some point in the Streams API spec. On Fri, May 17, 2013 at 6:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 16, 2013 at 10:14 PM, Takeshi Yoshino tyosh...@google.com wrote: I skimmed the thread before starting

Re: Overlap between StreamReader and FileReader

2013-05-17 Thread Takeshi Yoshino
On Fri, May 17, 2013 at 6:15 PM, Anne van Kesteren ann...@annevk.nl wrote: The main problem is that Stream per Streams API is not what you expect from an IO stream, but it's more what Blob should've been (Blob without synchronous size). What we want I think is a real IO stream. If we also

Overlap between StreamReader and FileReader

2013-05-16 Thread Takeshi Yoshino
StreamReader proposed in the Streams API spec is almost the same as FileReader. By adding the maxSize argument to the readAs methods (new methods or just add it to existing methods as an optional argument) and adding the readAsBlob method, FileReader can cover all what StreamReader provides. Has

Re: Overlap between StreamReader and FileReader

2013-05-16 Thread Takeshi Yoshino
I skimmed the thread before starting this and saw that you were pointing out some issues but didn't think you're opposing so much. Let me check requirements. a) We don't want to introduce a completely new object for streaming HTTP read/write, but we'll realize it by adding some extension

Re: RfC: LCWD of WebSocket API; deadline August 30

2012-08-09 Thread Takeshi Yoshino
No technical comments. A few editorial comments. CLOSING (numeric value 2) The connection is going through the closing handshake. The readyState can enter CLOSING also when close() is called before establishment. In that case, it's not going through closing handshake. // networking

Re: Proposal: add websocket close codes for server not found and/or too many websockets open

2012-05-28 Thread Takeshi Yoshino
The protocol spec has defined 1015, but I think we should not pass through it to the WebSocket API. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0437.html I think 1006 is the right code for all of WebSocket handshake failure, TLS failure and TCP connection failure. If the

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-29 Thread Takeshi Yoshino
On Thu, Jul 28, 2011 at 03:11, Anne van Kesteren ann...@opera.com wrote: HTML5 is mostly transport-layer agnostic. HTML5 is transport-layer agnostic though it involves communication with server in handling a, form element. The WebSocket API specifies much detail of transport-layer. What does

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread Takeshi Yoshino
Is new XHR spec going to make gzip mandatory for its underlying HTTP? On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor simetrical+...@gmail.comwrote: From the discussion here, it sounds like there are problems with WebSockets compression as currently defined. If that's the case, it might be

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread Takeshi Yoshino
On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com wrote: Is new XHR spec going to make gzip mandatory for its underlying HTTP? I do not think that analogy makes sense. The WebSocket protocol can

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-27 Thread Takeshi Yoshino
On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren ann...@opera.com wrote: On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com wrote: What do you mean by more places? XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc. So indicating what parts

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

2011-07-23 Thread Takeshi Yoshino
Resending. I've made mistake in processing public-webapps@w3.org confirmation page. On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino tyosh...@google.com wrote: On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren ann...@opera.com wrote: On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino tyosh