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

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

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

Is new XHR spec going to make gzip mandatory for its underlying HTTP? On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor wrote: > From the discussion here, it sounds like there are problems with > WebSockets compression as currently defined. If that's the case, it > might be better for the IETF to just

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

On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren wrote: > On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino > 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)

On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren wrote: > On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino > wrote: > >> What do you mean by "more places"? >> > > XMLHttpRequest is not the sole API for HTTP, there's also , , etc. > So indicating

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

On Thu, Jul 28, 2011 at 03:11, Anne van Kesteren wrote: > HTML5 is mostly transport-layer agnostic. > HTML5 is transport-layer agnostic though it involves communication with server in handling , element. The WebSocket API specifies much detail of transport-layer. What does make this difference

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

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 language

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

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 >

Overlap between StreamReader and FileReader

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 th

Re: Overlap between StreamReader and FileReader

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 to

Re: Overlap between StreamReader and FileReader

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 wrote: > On Thu, May 16, 2013 at 10:14 PM, Takeshi Yoshino > wrote: > > I skimmed the thread before starting this and saw that you w

Re: Overlap between StreamReader and FileReader

On Fri, May 17, 2013 at 6:15 PM, Anne van Kesteren 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 need Blob witho

Re: Overlap between StreamReader and FileReader

On Sat, May 18, 2013 at 1:38 PM, Jonas Sicking wrote: > For File reading I would now instead do something like > > partial interface Blob { > AbortableProgressFuture readBinary(BlobReadParams); > AbortableProgressFuture readText(BlobReadTextParams); > Stream readStream(BlobReadParams); > I

Re: Overlap between StreamReader and FileReader

On Sat, May 18, 2013 at 1:56 PM, Jonas Sicking wrote: > On Fri, May 17, 2013 at 9:38 PM, Jonas Sicking wrote: > > For Stream reading, I think I would do something like the following: > > > > interface Stream { > > AbortableProgressFuture readBinary(optional unsigned > > long long size); > >

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

On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren wrote: > On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino > 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 th

Re: Overlap between StreamReader and FileReader

On Fri, Aug 23, 2013 at 2:41 AM, Isaac Schlueter 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 APIs to a

Re: Overlap between StreamReader and FileReader

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 writeBuf

Re: Overlap between StreamReader and FileReader

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 wrote: > any peek(optional [Clamp] long long size, optional [Clamp] long long > offset); > peek with offset doesn

Re: Overlap between StreamReader and FileReader

On Thu, Sep 12, 2013 at 10:58 PM, Aymeric Vitte wrote: > 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 high level interface d

Re: Overlap between StreamReader and FileReader

On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte wrote: > 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 inside browsers (which

Re: Overlap between StreamReader and FileReader

On Fri, Sep 13, 2013 at 6:08 PM, Aymeric Vitte wrote: > 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, WebSocket, XHR, > WebRTC,

Re: Overlap between StreamReader and FileReader

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

On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte wrote: > > 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 of at th

Re: Overlap between StreamReader and FileReader

On Sat, Sep 14, 2013 at 12:03 AM, Aymeric Vitte wrote: > > 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 data while > reading

Re: Overlap between StreamReader and FileReader

On Wed, Sep 25, 2013 at 12:41 AM, Aymeric Vitte wrote: > 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, all the flow control s

Re: Overlap between StreamReader and FileReader

On Wed, Sep 25, 2013 at 10:55 PM, Aymeric Vitte wrote: > > 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 and > handle flow co

Re: Overlap between StreamReader and FileReader

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 StreamRea

Re: Overlap between StreamReader and FileReader

On Thu, Sep 26, 2013 at 6:36 PM, Aymeric Vitte wrote: > 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 MediaStream? (and others if

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

Sorry for the delay. On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren wrote: > On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino > wrote: > > In the spec, we have three "cancel"s > > - cancel an instance of fetch algorithm > > - cancel network activity &g

Re: Overlap between StreamReader and FileReader

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 wrote: > This looks nice. It looks like it should alre

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

On Fri, Oct 4, 2013 at 8:46 PM, Anne van Kesteren wrote: > On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino > wrote: > > On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren > wrote: > >> This is the end user terminate, correct? > > > > Yes. So, this inc

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

On Sat, Oct 5, 2013 at 1:26 AM, Anne van Kesteren wrote: > On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino > wrote: > > Sorry. I included network by mistake. I wanted to understand the abort > error > > well. > > > > Q: cancel by abort() is abort error? >

Re: [streams-api] Seeking status and plans

On Thu, Oct 10, 2013 at 11:34 PM, Feras Moussa wrote: > 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.g

Re: Overlap between StreamReader and FileReader

Sorry for blank of ~2 weeks. On Fri, Oct 4, 2013 at 5:57 PM, Aymeric Vitte wrote: > 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 = fileWriter.write(resultStr

Re: Overlap between StreamReader and FileReader

ol should be back and explicit, not sure right now how to > define it but I think it's 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. > > Regard

Re: Overlap between StreamReader and FileReader

On Wed, Oct 30, 2013 at 8:14 PM, Takeshi Yoshino wrote: > On Wed, Oct 23, 2013 at 11:42 PM, Aymeric Vitte wrote: > >> - pause: pause the stream, do not send eof >> > >> > Sorry, what will be paused? Output? > http://lists.w3.org/Archives/Public/public-webrtc/20

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

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 be

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

Hi Dean, On Thu, Oct 31, 2013 at 11:30 AM, Dean Landolt 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 its streams > refact

Re: publish WD of Streams API; deadline Nov 3

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 wrote: > On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola > wrote: > > I have concrete suggestions as to what such an API could look like—

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

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

Thoughts behind the Streams API ED

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

On Tue, Nov 5, 2013 at 2:11 AM, Takeshi Yoshino 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: Thoughts behind the Streams API ED

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

Re: Thoughts behind the Streams API ED

On Wed, Nov 6, 2013 at 7:33 PM, Aymeric Vitte wrote: > 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 bytestream > Reada

Re: Thoughts behind the Streams API ED

On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte wrote: > 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 about it (but > I saw

Re: Thoughts behind the Streams API ED

On Thu, Nov 7, 2013 at 6:27 PM, Aymeric Vitte wrote: > > Le 07/11/2013 10:21, Takeshi Yoshino a écrit : > > On Thu, Nov 7, 2013 at 6:05 PM, Aymeric Vitte wrote: > >> stop/resume: >> >> Indeed as I mentioned this is related to WebCrypto Issue22 but I don't &

Re: Thoughts behind the Streams API ED

On Fri, Nov 8, 2013 at 5:38 PM, Aymeric Vitte wrote: > 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. > Similar but a bit

Re: Thoughts behind the Streams API ED

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

On Fri, Nov 8, 2013 at 8:54 PM, Aymeric Vitte wrote: > 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 bytes), here

Re: Thoughts behind the Streams API ED

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

On Tue, Nov 12, 2013 at 5:23 PM, Aymeric Vitte wrote: > 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 écr

Re: Thoughts behind the Streams API ED

On Tue, Nov 12, 2013 at 5:20 PM, Aymeric Vitte wrote: > 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 > - close it >

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

two minor comments - add semicolons to lines of the example code in the introduction section? - 2nd paragraph in the conformance section, quote "must"?

Re: Request for feedback: Streams API

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 wrote: > Lo

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

Thanks for feedback. On Thu, Nov 21, 2013 at 4:56 PM, Feras Moussa wrote: > 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

Re: Request for feedback: Streams API

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: [promises] Guidance on the usage of promises for API developers

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 your

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

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 "possibl

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

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 onreadyst

Re: Fetch API

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 S

Re: Fetch API

On Mon, Jun 2, 2014 at 6:59 PM, Anne van Kesteren wrote: > On Thu, May 29, 2014 at 4:25 PM, Takeshi Yoshino > wrote: > > http://fetch.spec.whatwg.org/#dom-request > > Add steps to set client and context? > > That happens as part of the "restricted copy".

Re: Fetch API

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: XMLHttpRequest: uppercasing method names

On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren wrote: > On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell 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 not > have this list and always

Re: XMLHttpRequest: uppercasing method names

On Wed, Aug 13, 2014 at 12:15 AM, Brian Kardell wrote: > > On Aug 12, 2014 11:12 AM, "Takeshi Yoshino" wrote: > > > > On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren > wrote: > >> > >> On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell &g

Re: XMLHttpRequest: uppercasing method names

On Wed, Aug 13, 2014 at 1:05 AM, Anne van Kesteren wrote: > On Tue, Aug 12, 2014 at 5:15 PM, Brian Kardell 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() will never be able to explain s

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

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 non

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

me early stage after figuring out very basic issues and focus on the Fetch. Takeshi On Thu, Aug 14, 2014 at 4:03 PM, Anne van Kesteren wrote: > On Thu, Aug 14, 2014 at 6:20 AM, Takeshi Yoshino > wrote: > > We're implementing Streams API and integration of it and XHR > &g

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

On Thu, Aug 14, 2014 at 4:29 PM, Anne van Kesteren wrote: > On Thu, Aug 14, 2014 at 9:19 AM, Takeshi Yoshino > 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'r

Re: File API: reading a Blob

On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte wrote: > The fact is that most of the W3C groups impacted by streams (File, > indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, > etc, I must forget a lot here) seem not to care a lot about it and maybe > just expect streams t

Re: File API: reading a Blob

bably the spec should handle on a per case basis what 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) > > L

Re: File API: reading a Blob

representing chunks of the payload of a message. We need to discuss that first. > > Le 11/09/2014 08:36, Takeshi Yoshino a écrit : > > On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte > wrote: > >> Does your experimentation pipe the XHR stream to MSE? Obviously that >&

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

rg/hg/streams-api/raw-file/tip/Overview.htm doesn't have > much about WritableStreams. > > Jerry > > -Original Message- > From: Domenic Denicola [mailto:dome...@domenicdenicola.com] > Sent: Tuesday, October 14, 2014 10:18 AM > To: Aaron Colwell > Cc: Anne van Keste

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

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 wrote: > On 10/14/14 11:06 PM, Takeshi Yoshino wrote: > >> Not to confuse people, too late but I replace

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

On Fri, Oct 24, 2014 at 8:24 PM, Arthur Barstow 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 think it c

Re: =[xhr]

We're adding Streams API 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 sen

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren wrote: > On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola 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 control over what goes out. Bei

Re: =[xhr]

On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola wrote: > From: Takeshi Yoshino [mailto:tyosh...@google.com] > > > On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren > wrote: > >> On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola wrote: > >>> What do w

Re: =[xhr]

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 wrote: > On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola wrote: > > I still think we should just allow the dev

Re: =[xhr]

On Wed, Nov 19, 2014 at 1:45 AM, Domenic Denicola 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 > wrote: > >> How about padding the remaining bytes f

Re: Allow custom headers (Websocket API)

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 specifi

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 10:41 PM, Florian Bösch wrote: > On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino > 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)

er list is not a simple header > Set 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 wrote: > On

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 10:57 PM, Anne van Kesteren wrote: > On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann > wrote: > > A Websocket connection is established by making a HTTP Upgrade request, > > and the protocol is HTTP unless and until the connection is upgraded. > > Sure, but the server can

Re: Allow custom headers (Websocket API)

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 wrote: > Standardizing the approach would defi

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

+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: Art steps down - thank you for everything

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 co-chair of the Web > > Plat