On Wed, 11 Apr 2012 18:47:03 +0200, Boris Zbarsky wrote:
On 4/11/12 3:01 AM, Anne van Kesteren wrote:
How about
send(optional (ArrayBuffer or Blob or Document or DOMString or
FormData)? data = null)
I think that should be fine too, yes. I don't have a strong preference
for that over the o
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16303
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, Apr 11, 2012 at 4:47 PM, Joshua Bell wrote:
> Something I'm not seeing covered by the spec - what should the behavior be
> when inserting a value into an object store if the object store has a key
> generator and the key path is an Array? Should this be supported, or is it
> an error?
...
On Wed, Apr 11, 2012 at 8:15 PM, Boris Zbarsky wrote:
> On 4/11/12 5:54 PM, Charles Pritchard wrote:
>
>> Note that those have different performance characteristics, too; the
>>> latter involves a buffer copy.
>>>
>>
>> Are we stuck with a buffer copy (or copy on write) mechanism anyway?
>>
>
> Y
On Wed, Apr 11, 2012 at 5:54 PM, Kenneth Russell wrote:
> On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky wrote:
> > On 4/11/12 5:41 PM, Kenneth Russell wrote:
> >>
> >> Sending an ArrayBufferView would still have to use "arraybuffer" as
> >> the type of data. I don't think it would be a good ide
On 4/11/12 5:54 PM, Kenneth Russell wrote:
I haven't looked at WebSocket in enough detail to comment intelligently on
it.
I haven't really either, but if there were some peer-to-peer support,
then the receiving peer should still get an ArrayBuffer even if the
sender sent an ArrayBufferView.
T
On 4/11/12 5:54 PM, Charles Pritchard wrote:
Note that those have different performance characteristics, too; the
latter involves a buffer copy.
Are we stuck with a buffer copy (or copy on write) mechanism anyway?
Yes-ish; the question is how many copies there are.
What is the spec on chang
On Wed, Apr 11, 2012 at 7:19 PM, Kenneth Russell wrote:
> On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard wrote:
> > (I don't think there's any particular reason for ArrayBuffer to be
> opaque.
> > It would have been nice if ArrayBuffer acted like an Int8Array, so you
> can
> > access the content
On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard wrote:
> (I don't think there's any particular reason for ArrayBuffer to be opaque.
> It would have been nice if ArrayBuffer acted like an Int8Array, so you can
> access the contents as an array of bytes without an extra step.)
That's the way Java's
On Wed, Apr 11, 2012 at 3:40 PM, Charles Pritchard wrote:
> I know you've been circling this issue for awhile, so I'll put it out
> there again: yes, using typed arrays is difficult.
>
Typed arrays have a few gotchas, and design decisions that I disagree with,
but I wouldn't call them difficult
Something I'm not seeing covered by the spec - what should the behavior be
when inserting a value into an object store if the object store has a key
generator and the key path is an Array? Should this be supported, or is it
an error?
e.g. what is alerted:
var store = db.createObjectStore('store',
On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky wrote:
> On 4/11/12 5:41 PM, Kenneth Russell wrote:
>>
>> Sending an ArrayBufferView would still have to use "arraybuffer" as
>> the type of data. I don't think it would be a good idea to try to
>> instantiate the same subclass of ArrayBufferView on t
On 4/11/2012 2:50 PM, Boris Zbarsky wrote:
On 4/11/12 5:47 PM, Charles Pritchard wrote:
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky
wrote:
> Seems like right now passing a typed array to send() requires a bit
of extra
> hoop-jumping to pass the
On 4/11/12 5:47 PM, Charles Pritchard wrote:
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky wrote:
> Seems like right now passing a typed array to send() requires a bit
of extra
> hoop-jumping to pass the .buffer instead, right? Is that desirable?
On Wed, Apr 11, 2012 at 2:47 PM, Charles Pritchard wrote:
> On 4/11/2012 2:41 PM, Kenneth Russell wrote:
>>
>> On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky wrote:
>>>
>>> > Seems like right now passing a typed array to send() requires a bit of
>>> > extra
>>> > hoop-jumping to pass the .buff
On 4/11/12 5:41 PM, Kenneth Russell wrote:
Sending an ArrayBufferView would still have to use "arraybuffer" as
the type of data. I don't think it would be a good idea to try to
instantiate the same subclass of ArrayBufferView on the receiving
side.
I'm not sure what this means...
For XHR.send(
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky wrote:
> Seems like right now passing a typed array to send() requires a bit of extra
> hoop-jumping to pass the .buffer instead, right? Is that desirable?
It may be convenient to add an overload to
On 4/11/12 5:28 PM, Charles Pritchard wrote:
Adding .send(ArrayBufferView) doesn't seem like it'd hurt anything; it
would help in the case of subarray.
OK, we agree that far. ;)
Removing .send(ArrayBuffer) would hurt things.
That seems plausible. I'm more interested in the addition than t
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky wrote:
> Seems like right now passing a typed array to send() requires a bit of extra
> hoop-jumping to pass the .buffer instead, right? Is that desirable?
It may be convenient to add an overload to send() (presumably on both
XHR and WebSocket? Any
On 4/11/2012 1:16 PM, Boris Zbarsky wrote:
On 4/11/12 4:06 PM, Glenn Maynard wrote:
It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over. If you just pass "view.buffer", you'll send the *whole*
underly
On 4/11/12 5:04 PM, Charles Pritchard wrote:
When/if we start using the "Binary Data" instead of re-purposing typed
arrays.
Then we'll need to add more send() overloads, probably. What those
overloads will be, exactly, depends on the final state of the Binary
Data spec. I don't see the prob
On 4/11/2012 1:49 PM, Boris Zbarsky wrote:
On 4/11/12 4:40 PM, Charles Pritchard wrote:
That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.
I've got no idea where TC39 is taking things.
ArrayBuffer and ArrayBufferView and such are no
On 4/11/12 4:40 PM, Charles Pritchard wrote:
That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.
I've got no idea where TC39 is taking things.
ArrayBuffer and ArrayBufferView and such are not specced in TC39 at the
moment, and I'm no
On 4/11/2012 1:16 PM, Boris Zbarsky wrote:
On 4/11/12 4:06 PM, Glenn Maynard wrote:
It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over. If you just pass "view.buffer", you'll send the *whole*
underly
On 4/11/12 4:06 PM, Glenn Maynard wrote:
It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over. If you just pass "view.buffer", you'll send the *whole*
underlying buffer, not just the slice represented b
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703
Summary: I am suggesting a default value for the "code"
argument to the close method. I am currently
experimenting with this method and noticed that Chrome
and Firefox seem
On Wed, Apr 11, 2012 at 12:04 PM, Boris Zbarsky wrote:
> Seems like right now passing a typed array to send() requires a bit of
> extra hoop-jumping to pass the .buffer instead, right? Is that desirable?
>
It's a bit worse than that, actually: if you want to send only part of a
buffer, you have
On Wed, 2012-04-11 at 11:03 +1000, Silvia Pfeiffer wrote:
> Is there any possibility to attend remotely for specific topics?
Given the number of individuals in the room, the HTML Chairs at least
decided for not to have a polycom in the room. It didn't seem that the
room would be properly equipped
On 4/11/12 2:53 PM, Charles Pritchard wrote:
Yes; .buffer has stable semantics across many apis.
Like what?
It does feel awkward when first using it, but the design makes sense after some
experience.
My point is that we can have overloads taking both ArrayBuffer and
ArrayBufferView. Is t
Yes; .buffer has stable semantics across many apis.
It does feel awkward when first using it, but the design makes sense after some
experience.
On Apr 11, 2012, at 10:04 AM, Boris Zbarsky wrote:
> Seems like right now passing a typed array to send() requires a bit of extra
> hoop-jumping to
Great, thanks!
On Tue, Apr 10, 2012 at 5:30 PM, Arthur Barstow wrote:
> On Apr 10, 2012, at 2:28 PM, ext James Hawkins wrote:
>
> If we can schedule this for May 1, that would be fantastic. Unfortunately
> something last-minute has come up and I won't be able to attend May 2.
>
>
> I put Web Int
On Wed, Apr 11, 2012 at 10:41 AM, Ian Hickson wrote:
>
> I'm fine with making changes here. The following proposals seem to make
> the most sense, though I'm sure others could work too:
>
> 1. Leave it as is.
>
> 2. Make the .source attribute be of type (MessagePort or WindowProxy)?
> and add
I'm fine with making changes here. The following proposals seem to make
the most sense, though I'm sure others could work too:
1. Leave it as is.
2. Make the .source attribute be of type (MessagePort or WindowProxy)?
and add the port to .source, also leaving it in .ports[0].
3. Make th
On Tue, 10 Apr 2012, Paul Libbrecht wrote:
>
> Anywhere you look, Date.parse is "left to browser interpretation" with
> the only available standard, ISO-8601, not even being fully implemented
> in the modern browsers. The very informal w3c note is implemented, while
> this standard is too big.
I guess I'm not a big fan of removing ports[] from the connect event unless
we also remove it from MessageEvent entirely. All the same arguments you've
posed here also apply to MessageEvents in general, so I'd be opposed to
removing it in only one place.
I'm somewhat OK with keeping ports[] but al
Seems like right now passing a typed array to send() requires a bit of
extra hoop-jumping to pass the .buffer instead, right? Is that desirable?
-Boris
On 4/11/12 3:01 AM, Anne van Kesteren wrote:
How about
send(optional (ArrayBuffer or Blob or Document or DOMString or
FormData)? data = null)
I think that should be fine too, yes. I don't have a strong preference
for that over the overload version or vice versa.
-Boris
On 4/11/12 12:26 PM, Boris Zbarsky wrote:
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password argument
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified per
Hi All,
Apologies if this has been discussed before and I missed it, or have
forgotten about it.
Currently the IDL for the .open function looks as follows:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if a
On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking wrote:
I would prefer to expose the port through .source even if we can't get
rid of .ports[0] right now.
I think the longer we wait with removing it, the more legacy will be
created that relies on its existence.
The ports property is bas
On Tue, Apr 10, 2012 at 11:11 PM, Simon Pieters wrote:
> On Wed, 11 Apr 2012 07:56:48 +0200, Jonas Sicking wrote:
>
>> On Tue, Apr 10, 2012 at 10:44 PM, David Levin wrote:
>>>
>>> What is the backwards compatibility story for websites already using
>>> SharedWorkers with the interface that has b
On Wed, 11 Apr 2012 02:03:30 +0200, Boris Zbarsky wrote:
On 4/10/12 7:15 PM, Jonas Sicking wrote:
If I'm the only one who prefer the other behavior then we should stick
to what the spec already says. I'll make sure Gecko maintains that
behavior as we implement our new WebIDL bindings.
One not
43 matches
Mail list logo
