Apologies for the slow response. I wanted to go back and reread the
relevant specs before I said anything more. Having done so, I found
that XHR and FileReader were more similar than I had remembered.
However, I believe I also found that the exception solution is just as
consistent with XHR as th
On Mon, Apr 18, 2011 at 5:28 PM, Eric Uhrhane wrote:
> On Fri, Apr 15, 2011 at 4:01 PM, Arun Ranganathan wrote:
>> On 4/15/11 6:29 PM, Aryeh Gregor wrote:
>>>
>>> On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda wrote:
* The FileError object is a bit awkward to work with. I found that I
On Fri, Apr 15, 2011 at 4:01 PM, Arun Ranganathan wrote:
> On 4/15/11 6:29 PM, Aryeh Gregor wrote:
>>
>> On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda wrote:
>>>
>>> * The FileError object is a bit awkward to work with. I found that I
>>> frequently had every reason to expect my calls to succeed
On Mon, Apr 18, 2011 at 4:52 PM, Garrett Smith wrote:
> A test with 0 assertions could be used to test exceptions but only if
> the testing framework provides for "@throws" annotation (my
> TestRunner.js does).
testharness.js has an assert_throws() function that can be used in
cases where an exce
On 4/18/11 3:55 PM, Adrian Bateman wrote:
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInPro
On Mon, Apr 18, 2011 at 12:55 PM, Adrian Bateman wrote:
> On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
>> On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman
>> wrote:
>> > On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
>> >> Yes. I.e. the semantics of readAsX is basically:
>> >>
On 4/18/11, Aryeh Gregor wrote:
> On Sun, Apr 17, 2011 at 9:38 PM, Garrett Smith
> wrote:
>> The superfluous, badly worded maladvice remains: "Within each test one
>> may have a number of asserts."
>>
>> Awkward wording to explicitly mention that such bad practice is allowed.
>
> I'll reiterate t
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
> On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman
> wrote:
> > On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
> >> Yes. I.e. the semantics of readAsX is basically:
> >>
> >> readAsX(...) {
> >> if (requestInProgress)
> >> abor
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman wrote:
> On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
>> On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman
>> wrote:
>> > Yes, we could live with it but the semantics are more complex. Is this the
>> > same as calling abort() then readAsXX
On Sun, Apr 17, 2011 at 9:38 PM, Garrett Smith wrote:
> The superfluous, badly worded maladvice remains: "Within each test one
> may have a number of asserts."
>
> Awkward wording to explicitly mention that such bad practice is allowed.
I'll reiterate that I think multiple asserts per test are us
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
> On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman
> wrote:
> > Yes, we could live with it but the semantics are more complex. Is this the
> > same as calling abort() then readAsXXX()?
>
> Yes. I.e. the semantics of readAsX is basically:
>
A couple of comments on the Server-Sent Events draft proposal:
Section 4:
When close() is called on the EventSource object, the initial connection may
not have been established yet, or a reconnection could be scheduled for some
arbitrary time in the future (not currently being attempted). Should t
12 matches
Mail list logo
