Re: Overlap between StreamReader and FileReader
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 readStream(BlobReadParams);
I'd name it asStream. readStream operation here isn't intended to do any
read, i.e. moving data between buffers, (like ArrayBufferView for
ArrayBuffer) right?
Or it's gonna clone the Blob's contents and wrap with the Stream interface
as we cannot discard contents of a Blob and it'll be inconsistent with
the semantics (implication?) we're going to give to the Stream interface?
Re: Overlap between StreamReader and FileReader
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 unsigned
long long size);
AbortableProgressFutureString readText(optional unsigned long long
size, optional DOMString encoding);
AbortableProgressFutureBlob readBlob(optional unsigned long long
size);
ChunkedData readBinaryChunked(optional unsigned long long size);
ChunkedData readTextChunked(optional unsigned long long size);
};
interface ChunkedData : EventTarget {
attribute EventHandler ondata;
attribute EventHandler onload;
attribute EventHandler onerror;
};
Actually, we could even get rid of the ChunkedData interface and do
something like
interface Stream {
AbortableProgressFutureArrayBuffer readBinary(optional unsigned
long long size);
AbortableProgressFutureString readText(optional unsigned long long
size, optional DOMString encoding);
AbortableProgressFutureBlob readBlob(optional unsigned long long size);
AbortableProgressFuturevoid readBinaryChunked(optional unsigned
long long size);
AbortableProgressFuturevoid readTextChunked(optional unsigned long
long size);
};
where the ProgressFutures returned from
readBinaryChunked/readBinaryChunked delivers the data in the progress
notifications only, and no data is delivered when the future is
actually resolved. Though this might be abusing Futures a bit?
This is also clear read-only-once interface as well as onmessage() approach
because there's no attribute to accumulate the result value. The fact that
the argument for accept callback is void strikes at least me that the value
passed to progress callback is not an accumulated result but each chunk
separately.
As the state transition of Stream would be simple enough to match Future, I
think technically it's ok and even better to employ it than readyState +
callback approach.
But is everyone fine with making it mandatory to get used to programming
with Future to use Stream?
Re: Overlap between StreamReader and FileReader
On Sat, May 18, 2013 at 5:56 AM, Jonas Sicking jo...@sicking.cc wrote: where the ProgressFutures returned from readBinaryChunked/readBinaryChunked delivers the data in the progress notifications only, and no data is delivered when the future is actually resolved. Though this might be abusing Futures a bit? Yeah, futures represent a value. This is an event stream (that does not keep track of history). -- http://annevankesteren.nl/
Re: [XHR] anonymous flag
On Sat, May 18, 2013 at 8:41 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: BTW - have you considered allowing setting withCredentials to false for same-origin resources? I suspect that would break sites. Making a boolean a tri-state with a default depending on an external variable is also super confusing. -- http://annevankesteren.nl/
Re: Overlap between StreamReader and FileReader
On Sat, May 18, 2013 at 7:36 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, May 18, 2013 at 5:56 AM, Jonas Sicking jo...@sicking.cc wrote: where the ProgressFutures returned from readBinaryChunked/readBinaryChunked delivers the data in the progress notifications only, and no data is delivered when the future is actually resolved. Though this might be abusing Futures a bit? Yeah, futures represent a value. This is an event stream (that does not keep track of history). It's not exactly an event stream since the exact events isn't what matters here. I.e. you'll get different events in different implementations, and there are no guarantees that the events themselves will be meaningful. But yeah, I agree it's not representing a value and so it's an abuse of Future's semantics. / Jonas
Re: Re: [XHR] anonymous flag
BTW - have you considered allowing setting withCredentials to false for same-origin resources? I suspect that would break sites. Possibly, but I find it unlikely - if it's set, it's most likely usually set to true, not false, and it's also most likely rarely set for same-origin requests. Wonder how hard it would be to ship a test in some beta- or preview build of some browser..? 8-) Making a boolean a tri-state with a default depending on an external variable is also super confusing. To whom? Defaults to true for same-origin, false for cross-origin, can be set to override seems to give authors a behaviour that's relatively intuitive. (Authors would not really have to consider the odd tri-state underpinnings, it still looks like a boolean except with a variable default behaviour). It might be weird and confusing to implement though.. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] anonymous flag
On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: BTW - have you considered allowing setting withCredentials to false for same-origin resources? I suspect that would break sites. Possibly, but I find it unlikely - if it's set, it's most likely usually set to true, not false, and it's also most likely rarely set for same-origin requests. Wonder how hard it would be to ship a test in some beta- or preview build of some browser..? 8-) Making a boolean a tri-state with a default depending on an external variable is also super confusing. To whom? Defaults to true for same-origin, false for cross-origin, can be set to override seems to give authors a behaviour that's relatively intuitive. (Authors would not really have to consider the odd tri-state underpinnings, it still looks like a boolean except with a variable default behaviour). It seems confusing to anyone who reads the value. What would it return in the various situations? I.e. before and after .open() has been called, and if .open() was called with a cross-origin URL or not. / Jonas
Re: Re: Re: [XHR] anonymous flag
Making a boolean a tri-state with a default depending on an external variable is also super confusing. To whom? It seems confusing to anyone who reads the value. Good point. What would it return in the various situations? I.e. before and after .open() has been called, and if .open() was called with a cross-origin URL or not. Simplest possibility seems to be undefined if not set, true or false respectively if it was set. Of course this doesn't reflect whether credentials will be sent in the request or not - but that doesn't really happen today either, we don't automagically make it return true for same-origin and false for cross-origin requests, so it's not much of a change. Most capability detection I've seen uses the sensible 'withCredentials' in xhr form which will still work. -- Hallvord R. M. Steen Core tester, Opera Software
