Re: [XHR] chunked

[Wenbo Zhu]

On Thu, Sep 27, 2012 at 12:21 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> > From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com]
> >
> > On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead
> >  wrote:
> > > In my observation of the current IE behavior, the Stream is for
> download
> > only. XHR gets the data from the server and buffers it. The consumer of
> > the stream then pulls data as needed which is extracted from the buffer.
> >
> > I see, so the bit where it says you can pass it to send() we should
> > maybe not add for now if it's not going to do something useful.
>
> I honestly haven't tested that part, but this seems safe (it can be added-
> in later if need be).
>
Could you confirm if it actually works ... even if the spec fails to talk
about it? :)

Re: [IndexedDB] blocked event could be an error

[Jonas Sicking]

On Mon, Oct 1, 2012 at 11:25 AM, David Grogan  wrote:
>
>
> On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking  wrote:
>>
>> On Thu, Sep 27, 2012 at 6:47 AM, João Eiras  wrote:
>> >
>> >>>   http://odinho.html5.org/IndexedDB/spec/Overview.html
>> >>
>> >>
>> >> Like I said, I think it's too late to make such a big change. I
>> >> believe it's much too late to make such a change in IE10, and we have
>> >> been shipping Firefox with the current behavior for quite a while now
>> >> (and are about to unprefix with our current behavior).
>> >>
>> >> / Jonas
>> >
>> >
>> > Sorry but it is not late. It's actually quite early and the right time.
>>
>> I don't know by what measure it's "quite early" or "the right time".
>
>
> It'd be the right time because though IDB usage is picking up, it's still
> relatively low. Optimally this change would have been made a few months or
> years ago, but now is better than later.
>
>> We've passed Last Call, there are 3 shipping implementations, all of
>> which have considered their implementation complete enough to switch
>> from prefixed implementations to unprefixed ones. They all implement
>> the behavior that you are proposing to change.
>
>
> We'd be ok with changing this, our unprefixedness notwithstanding. I think
> the pain it would save developers down the road would make up for the
> immediate pain it would cause to both vendors and developers. But that's
> just a judgment call, I'm relying on intuition and obviously have no data
> about what the future will hold.
>
> To balance the concerns of open with complicated semantics and
> backward-compatibility, I propose that we add two methods to IDBFactory:
> openOrFail and openOrBlock.  Most introductory IDB tutorials and examples
> would steer developers towards openOrFail.  The current open method would be
> an alias for openOrBlock.  That open's documentation would be "[deprecated]
> alias for openOrBlock" should give developers some pause about using it just
> because it has the simplest name.

My perception is that it's too late for microsoft to change this for
IE10. I also know that developers will strongly prefer .open to
.openOrX purely based on the length of the name.

I think that leaves us with keeping .open as-is and adding a
.openOrFail function.

I'd be ok with doing that. If we do it for v1 or not I don't have a
strong opinion of.

/ Jonas

Re: [IndexedDB] blocked event could be an error

[David Grogan]

On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking  wrote:

> On Thu, Sep 27, 2012 at 6:47 AM, João Eiras  wrote:
> >
> >>>   http://odinho.html5.org/IndexedDB/spec/Overview.html
> >>
> >>
> >> Like I said, I think it's too late to make such a big change. I
> >> believe it's much too late to make such a change in IE10, and we have
> >> been shipping Firefox with the current behavior for quite a while now
> >> (and are about to unprefix with our current behavior).
> >>
> >> / Jonas
> >
> >
> > Sorry but it is not late. It's actually quite early and the right time.
>
> I don't know by what measure it's "quite early" or "the right time".
>

It'd be the right time because though IDB usage is picking up, it's still
relatively low. Optimally this change would have been made a few months or
years ago, but now is better than later.

We've passed Last Call, there are 3 shipping implementations, all of
> which have considered their implementation complete enough to switch
> from prefixed implementations to unprefixed ones. They all implement
> the behavior that you are proposing to change.
>

We'd be ok with changing this, our unprefixedness notwithstanding. I think
the pain it would save developers down the road would make up for the
immediate pain it would cause to both vendors and developers. But that's
just a judgment call, I'm relying on intuition and obviously have no data
about what the future will hold.

To balance the concerns of open with complicated semantics and
backward-compatibility, I propose that we add two methods to IDBFactory:
openOrFail and openOrBlock.  Most introductory IDB tutorials and examples
would steer developers towards openOrFail.  The current open method would
be an alias for openOrBlock.  That open's documentation would be
"[deprecated] alias for openOrBlock" should give developers some pause
about using it just because it has the simplest name.

At least the Amazon cloud reader uses IndexedDB. I've started
> receiving enough questions about IDB that I would imagine that there
> are more websites deployed which uses it.
>
> / Jonas
>
>

Re: In WebIDL, should having a .prototype on interface objects be optional?

[Rick Waldron]

On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> From: Rick Waldron [mailto:waldron.r...@gmail.com]
> >
> > I wasn't specific enough in my original question, but I did note that I
> wasn't referring to construction exceptions, so I'm guessing by your
> response that you actually _just_ meant testing for "constructability". I
> apologize for not being clearer, but I was actually referring to the URL
> string parameter itself, and how to test if passing an argument to the
> constructor is supported (the example I gave falls short of answering that
> question).
> >
> >Loosely related... will invalid URL string parameters throw in the same
> manner that invalid selectors throw? eg. context.querySelector("?")
>
> Hmm, that's not a question for WebIDL, as far as I know. The spec defining
> the constructor behavior would need to specify that.
>

Fair enought, apologies for the noise. Thanks!

Rick

RE: In WebIDL, should having a .prototype on interface objects be optional?

[Travis Leithead]

From: Rick Waldron [mailto:waldron.r...@gmail.com] 
>
> I wasn't specific enough in my original question, but I did note that I 
> wasn't referring to construction exceptions, so I'm guessing by your response 
> that you actually _just_ meant testing for "constructability". I apologize 
> for not being clearer, but I was actually referring to the URL string 
> parameter itself, and how to test if passing an argument to the constructor 
> is supported (the example I gave falls short of answering that question). 
>
>Loosely related... will invalid URL string parameters throw in the same manner 
>that invalid selectors throw? eg. context.querySelector("?")

Hmm, that's not a question for WebIDL, as far as I know. The spec defining the 
constructor behavior would need to specify that.

Re: [admin] Call for Editor for XHR REC track doc

[Arthur Barstow]

On 9/25/12 7:00 PM, ext Arthur Barstow wrote:

If you are interested in this Editor position, please contact me offlist.


Thanks to those that expressed interest in helping move the XHR spec 
along the Recommendation track.


We selected three co-Editors for this spec: Julian Aubourg (jQuery), 
Jungkee Song (Samsung) and Hallvord Steen (Opera).


-Regards, Art and Chaals


[XHR] 

Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

[Ted Mielczarek]

On Wed, Sep 26, 2012 at 10:27 AM, Arthur Barstow  wrote:
> * Gamepad - Scott, Ted - what's the status of the spec and its
> implementation?

We probably need to discuss a bit more, but I think the spec is pretty
close to a first version. The one large issue that we haven't tackled
yet is how button layouts should be described. Scott and I have talked
about that a bit, but we need to nail it down. I'm reasonably happy
with the rest of it, I think there's enough there to be useful without
wandering off into more complex territory.

AFAIK Chrome has shipped an implementation. The Firefox implementation
is hung up in review still because it's been a side project for me.
I'd like to get it landed in nightly builds soon.

-Ted