Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
Arun Ranganathan: I've pinged heycam to see if this is a proper use of the sequence type. I'm not sure it allows for such a variation in parameters. I agree with Boris, it makes sense to use sequence<> here. Whenever you just want to take a list of values in an operation argument, and you don't want to keep a reference to a platform array object, you should use a sequence<>. But I also agree with Glenn that if you did use T[], and the implementation knows that it will never use the temporary platform array object that gets created when converting the (for example) JS Array object, it should be able to skip the actual platform array object creation.
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
On 9/10/12 6:36 PM, Arun Ranganathan wrote: I've pinged heycam to see if this is a proper use of the sequence type. I'm not sure it allows for such a variation in parameters. Sequence allows any WebIDL type as a sequence element. So for example, you can do this: sequence<(sequence<(DOMString or Element or ArrayBufferView)> or DOMString)> Not that you should do such a thing. ;) -Boris
Re: [FileAPI] Blob constructor should probably take a sequence, not an IDL array object
I've pinged heycam to see if this is a proper use of the sequence type. I'm
not sure it allows for such a variation in parameters.
-- A*
On Sep 9, 2012, at 2:31 PM, Boris Zbarsky wrote:
> On 9/9/12 12:13 PM, Glenn Maynard wrote:
>>In particular, a Blob represents immutable binary data. That means
>>that it has to copy the input anyway. Given that, it doesn't make
>>sense to pass the input by reference if the caller _does_ happen to
>>have an WebIDL array object.
>>
>> That doesn't mean it copies the array itself, though.
>
> That's true, but in most cases (certainly the ones where a JavaScript array
> will be passed in) that would happen anyway.
>
>> (Though both ways, this seems like an implementation detail
>
> It's not quite.
>
>> I'd expect a mature binding system to let you annotate implementations to say
>> things like "make a copy for me instead of passing it in by reference"
>> and "don't make a copy even though WebIDL requires it, because we
>> fulfill that requirement as a side-effect".)
>
> Those are both incredibly fragile. Consider some other random spec that has
> IDL like this.
>
> interface Foo {
>// Returns the argument passed to the constructor
>(ArrayBuffer or ArrayBufferView or Blob or DOMString)[]
> getInitData();
> };
> Blob implements Foo;
>
> Now suddenly your annotation is a bug.
>
> So in practice binding systems aren't particularly likely to implement such
> annotations because of the increased fragility they introduce. The whole
> point of having IDL for bindings is to _reduce_ fragility
>
> The upshot is that there are practical drawbacks (slowing down the common use
> case, as far as I can tell) and at best theoretical benefits (since nothing
> actually _produces_ platform arrays of the above union!).
>
> By the way, note that if something produces a DOMString[] and you pass _that_
> to a blob constructor as currently defined, then what will happen per spec is
> that the input will be converted to a sequence and then a new
> platform array object will be created and the sequence copied into it. So
> you'll still get passing by value, not by reference. The only way to get
> passing by reference is if you're given a T[] where T exactly matches your
> array element type.
>
> Basically, platform arrays are only useful if you both produce and consume
> them in the same interface, as far as I can tell...
>
> -Boris
>
Re: Call for Review of Content Security Policy 1.0
On 9/7/12 12:05 PM, ext Hill, Brad wrote: The Web Application Security Working Group at the W3C is planning to advance Content Security Policy 1.0 to Candidate Recommendation – a final set of features and syntax – and is seeking wide review of the document at this time. We would especially value the input of members of the WebApps WG. http://www.w3.org/TR/2012/WD-CSP-20120710/ Brad - I noticed the above LCWD says the comment deadline is August 24. What is the (extended) deadline? If there is a document that is being used to "track" this LCWD's comments, please let us know its URI. -Thanks, AB
[quota-api] API change suggestions
Hi,
I'm very happy with the API changes we where able to make to the Quota
API, but there's a method name we have left untouched and that I haven't
figured out how to tackle until today: queryUsageAndQuota.
The name is horrendous and is going to make developers cringe. It's also
not very extensible should need arise to provide extra information in the
future.
Here's a suggestion to fix it:
1) create a new StorageQuotaInfo interface:
WebIDL:
interface StorageQuotaInfo {
readonly attribute unsigned long long quota;
readonly attribute unsigned long long usage;
};
2) Rename StorageUsageCallback to StorageInfoCallback and pass it a
StorageQuotaInfo instead of two ints:
WebIDL:
callback StorageInfoCallback = void (StorageQuotaInfo storageQuotaInfo);
3) Rename queryUsageAndQuota to getInfo:
WebIDL:
interface StorageQuota {
void getInfo (in StorageInfoCallback successCallback, in optional
StorageErrorCallback errorCallback);
...
};
The examples in the spec would be rewritten as shown here:
https://gist.github.com/3690242
Thoughts?
Again, happy to contribute those changes if there's interest.
Best,
--tobie
[quota-api] Need for session storage type
Hi all, Following a recent conversation with Jonas (and contrary to what I initially claimed here) there's value in adding a third storage type to the Quota API: Session storage. Contrary to temporary storage which might not get wiped across UA sessions, Session storage MUST get wiped when the session is closed. Happy to provide patch if there's agreement this is a valuable addition to the spec. Best, --tobie
Re: [XHR] Event processing during synchronous request
On Mon, Sep 10, 2012 at 10:05 AM, Mike Wilson wrote: > Thanks. So I understand it is the HTML specification reference > that provides details on this behaviour for the XHR spec. > I'll look further there as its fetching section by itself > doesn't directly express the relationship between synchronous > and a stopped event loop (although as a programmer I can infer > this relationship). Well yeah, shit's complicated. HTML fetch can be invoked either synchronously or asynchronously. When invoked synchronously it's as part of some task already and since the event loop is not manually spun no other tasks will run at that time. When invoked asynchronously HTML fetch itself queues tasks on the event loop that then cause various things to happen per XMLHttpRequest, such as dispatching progress events. -- http://annevankesteren.nl/
RE: [XHR] Event processing during synchronous request
Anne van Kesteren wrote: > On Sun, Sep 9, 2012 at 6:33 PM, Mike Wilson > wrote: > > I didn't find statements directly addressing this in > > http://www.w3.org/TR/XMLHttpRequest/ > > or > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/fe > tching-resourc > > es.html > > but maybe there are indirect relationships between > > specification sections that I am missing? > > What you are missing is that for synchronous fetching the event loop > stops working so incoming events will not be processed. Thanks. So I understand it is the HTML specification reference that provides details on this behaviour for the XHR spec. I'll look further there as its fetching section by itself doesn't directly express the relationship between synchronous and a stopped event loop (although as a programmer I can infer this relationship). Best regards Mike
Re: [XHR] Event processing during synchronous request
On Sun, Sep 9, 2012 at 6:33 PM, Mike Wilson wrote: > I didn't find statements directly addressing this in > http://www.w3.org/TR/XMLHttpRequest/ > or > http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resourc > es.html > but maybe there are indirect relationships between > specification sections that I am missing? What you are missing is that for synchronous fetching the event loop stops working so incoming events will not be processed. -- http://annevankesteren.nl/
