Re: [XHR2] why have an asBlob attribute at all?
On Fri, 29 Oct 2010 07:55:58 +0200, David Flanagan da...@davidflanagan.com wrote: I doubt I understand all the implementation issues. But if there really is some reason to have this blob/non-blob decision point before calling send(), can I suggest that instead of confusing the XHR API with it, it be moved into a separate BlobHttpRequest interface that has only reponseBlob and does not even define responseText, etc. Brainstorming here. We could choose to always expose resonseArrayBuffer and keep it together with responseText and responseXML. And for applications that are worried about memory usage or care about very large files we could have BlobXMLHttpRequest similar to AnonXMLHttpRequest. We'd abstract some things out from XMLHttpRequest so BlobXMLHttpRequest does not have the other response* members and so that AnonXMLHttpRequest does not need withCredentials and the fourth and fifth parameter to open(). -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] why have an asBlob attribute at all?
On Fri, Oct 29, 2010 at 4:08 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 29 Oct 2010 07:55:58 +0200, David Flanagan da...@davidflanagan.com wrote: I doubt I understand all the implementation issues. But if there really is some reason to have this blob/non-blob decision point before calling send(), can I suggest that instead of confusing the XHR API with it, it be moved into a separate BlobHttpRequest interface that has only reponseBlob and does not even define responseText, etc. Brainstorming here. We could choose to always expose resonseArrayBuffer and keep it together with responseText and responseXML. And for applications that are worried about memory usage or care about very large files we could have BlobXMLHttpRequest similar to AnonXMLHttpRequest. We'd abstract some things out from XMLHttpRequest so BlobXMLHttpRequest does not have the other response* members and so that AnonXMLHttpRequest does not need withCredentials and the fourth and fifth parameter to open(). Could we, um, not include the word XML in any new things? BlobHttpRequest seems much less silly. ~TJ
Agendas for WebApps' Nov 1-2 f2f meeting
Hi All, I now consider the agenda for WebApps' meeting on Tuesday November 2 as confirmed and the agenda items for that day have not changed for a few weeks: http://www.w3.org/2008/webapps/wiki/TPAC2010#Tuesday.2C_November_2 On Monday November 1, the widgets group will meet with WAI's Protocols and Formats WG (09:30-10:30). I am trying to arrange meeting time with the I18N Core WG re Widget Interface spec but that is currently not confirmed (if/when confirmed, I will send the logistics to public-webapps): http://www.w3.org/2008/webapps/wiki/TPAC2010#Monday.2C_November_1 *With the exception of the 1-2 widget-related meetings mentioned above, WebApps WILL NOT MEET on November 1.* To facilitate remote participation, the W3C's Voice Conference Bridge will be used for all of the meetings: http://www.w3.org/2008/webapps/wiki/TPAC2010#Meeting_Logistics -Art Barstow
Re: XHR: Unicode signature stripping
On Tue, 05 Oct 2010 05:25:20 +0200, Bjoern Hoehrmann derhoe...@gmx.net wrote: In http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ section 3.7.5. does not explicitly call out that the bytes corresponding to the Unicode signature are treated as Unicode signature and are thus stripped from the input. It should. I am just going to treat this as an editorial oversight and fix it in the editor's draft without opening a bug for it as I did with the larger errors. I hope that is okay. I do note that failing to discriminate between types that allow for a Unicode signature and types that do not creates interoperability problems. application/json for instance prohibits using it, and as a consequence many parsers reject it, whereas using it would appear to work fine in AJAX setups. There are similar such issues already, indeed. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] why have an asBlob attribute at all?
On Fri, 29 Oct 2010 13:08:07 +0200, Anne van Kesteren ann...@opera.com wrote: Brainstorming here. We could choose to always expose resonseArrayBuffer and keep it together with responseText and responseXML. And for applications that are worried about memory usage or care about very large files we could have BlobXMLHttpRequest similar to AnonXMLHttpRequest. We'd abstract some things out from XMLHttpRequest so BlobXMLHttpRequest does not have the other response* members and so that AnonXMLHttpRequest does not need withCredentials and the fourth and fifth parameter to open(). Nevermind, then we'd need AnonBlobXMLHttpRequest too for completeness. Not so great. -- Anne van Kesteren http://annevankesteren.nl/
Re: DOM collections index out of bounds and JavaScript.
Cameron McCormack:
I don’t know that sequence is appropriate for this. They are meant
to be for pass-by-value lists.
Anne van Kesteren:
I'm not sure I follow this. Could you elaborate a bit?
As currently defined, sequence types are used solely to represent lists
of values, and not objects that have other methods on them. Also, those
lists are passed by value. If you had an operation that took a
sequencelong argument, then in ECMAScript you could pass an Array
object where each of the elements were treated as longs (and converted
appropriately). The object on which you called the method wouldn’t be
able to keep a reference to the Array.
This is kind of different from NodeLists etc., which are objects that
keep a list of values. You can pass references to these objects around
and not expect a copy of the elements to be taken each time you do that.
Array types are intended to be like these objects, in that copies won’t
be made of their element lists. They still don’t allow operations to be
defined on them, though, if you are looking for that.
Is the issue here that you can’t use a base interface because then you
would lose some type specificity, e.g.
interface Collection {
attribute unsigned long length;
getter any item(unsigned long index);
}
where you need to use “any” because you don’t know what the type of the
derived interface elements will be?
Well, and you would need to define that base interface somewhere and
all other specifications would need to use it.
A minor issue, I guess.
But I thought this was the point of sequence. I have been using it
that way in the CSSOM at least to replace all these dreaded
SomethingList interfaces/objects. Maybe we should introduce something
else for it?
Depends what you are using them for. For example if you have an
attribute of type sequenceT, that’s almost certainly not what you
want. (And in fact I should disallow it.) You don’t want a whole new
Array object constructed each time you get the property value.
So it sounds like array types are more appropriate here.
I don’t think anyone is using array types yet. Consequently, they could
do with some review. Have a read through
http://dev.w3.org/2006/webapi/WebIDL/#es-array to see how they’re meant
to be implemented in ECMAScript. Having funky [[DefineOwnProperty]]
behaviour, I’m sure some people will have issues with it. Maybe one day
it’ll be possible to define array-like proxy objects in ECMAScript, in
which case we could target them instead.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: DOM collections index out of bounds and JavaScript.
On 10/29/10, Cameron McCormack c...@mcc.id.au wrote:
Cameron McCormack:
I don’t know that sequence is appropriate for this. They are meant
to be for pass-by-value lists.
Anne van Kesteren:
I'm not sure I follow this. Could you elaborate a bit?
As currently defined, sequence types are used solely to represent lists
of values, and not objects that have other methods on them. Also, those
lists are passed by value. If you had an operation that took a
sequencelong argument, then in ECMAScript you could pass an Array
object where each of the elements were treated as longs (and converted
appropriately). The object on which you called the method wouldn’t be
able to keep a reference to the Array.
Objects references are passed as value in ES but that doesn't mean the
same thing you're intending here. Here, by pass by value, you mean
to convey that a copy of value of the object is passed.
Object references are passed by value in ES. Dmitry Soshnikov explains
this pretty well:
http://dmitrysoshnikov.com/ecmascript/chapter-8-evaluation-strategy/#ecmascript-implementation
// Modifying an Array that was passed to drawPolygon() is guaranteed not to
// have an effect on the Canvas, since the Array is effectively passed by value.
a[0] = 20;
Where is Array host object is implemented?
A method that accepts an array can use that array without storing a
reference to it. And if it needs those items, then it can make a
defensive copy of the Array.
Below is an example of how that would look in user-defined code.
Anything that is possible in user-defined code can be implemented in
native code.
var o = new function() {
var items = [],
slice = Array.prototype.slice;
function setItems(a) {
items = slice.call(a);
}
function getItems(a) {
return slice.call(items);
}
this.setItems = setItems;
this.getItems = getItems;
};
var a = [1, 2, 3];
o.setItems(a);
The difference here is that the object that was passed in uses normal
ES syntax; it's pass by value (value of reference) not referenced by
the object. The effect is what you wanted, I think, and that is that
1) the method that accepts the array makes a defensive copy of it and
2) that the method (or getter) that returns the array always returns a
new copy of it.
But where is the array host object used?
[...]
interface Collection {
attribute unsigned long length;
getter any item(unsigned long index);
}
where you need to use “any” because you don’t know what the type of the
derived interface elements will be?
Well, and you would need to define that base interface somewhere and
all other specifications would need to use it.
A minor issue, I guess.
That seems like the main issue to me. What are a Collection object's
indexed properties? Are they real object properties or is there a
proxy for [[Get]] and [[Has]]? Both behaviors can be seen in
implementations but it varies, depending on the implementation and on
the object.
But where are proxies really needed? How important is it, for example,
for document.styleSheets[-1] to throw an index out of bounds
exception, or for document.childNodes(9) to return null instead of
undefined?
It seems that some implementations have gone out of the way to use
proxies to adhere to the spec to fulfill the odd cases above (albeit
inconsistently) while others have chosen to just use property access
to return undefined. How important are those cases? Do we have any
bug reports for implementations returning `undefined` instead of
throwing/returning null?
I get that the spec requires ob[n] to delegate to item, and so for
that a proxy is needed. But what type of situation is it really
necessary for obj[n] to delegate to item? Which Collections really
need a proxy to function as required by code?
[...]
Garrett
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On 10/28/10 11:29 PM, Jonas Sicking wrote: Personally I like the proposed responseType solution. The one where you pick one up front and it throws if you ask for something else, right? I agree that it has a downside in that it doesn't allow figuring out the type as data starts coming in. Well, that, and the whole throws exceptions bit... However I think this is a much less common case then knowing the type before the request is made. I agree that far, yes. I do think that supporting the case of downloading something which type you don't know is a use-case that we need to support. But I don't think that the way to do that is to have XHR parse things into every conceivable format at the same time. I'm not suggesting it do that. I also am not a big fan of the lazy-decode-into-whatever-format-users-want. It makes it much too easy for a site to use up more memory and CPU than it needs. As opposed to having sites decode themselves? I'm not sure there's much difference. For users that can handle progressive handling of the downloaded content, keeping all the so-far-downloaded data in memory is pure waste. Sure. The question is how to make their lives better without making others' lives worse (or at least too much worse?). (To make matters worse, we don't just keep all the data in memory, but for each additional downloaded piece of content, we over and over reallocate a ever-expanding block of memory. That seems like an implementation detail. Nothing is really preventing segmented storage of the data (not even the responseArrayBuffer getter, if it were added). For the case when it's known what type of response is expected this seems to work very well. As long as only one entity is doing the expecting, right? Right now jquery expects to get responseText, so if you expect something else you can't use jquery's XHR wrappers, say For the case when looking at the response body is required to determine how the response should be handled I'm less sure. One solution would be to say that people can just use .responseType = binary or .responseType = blob and then do the processing themselves. This actually seems ok to me if we have APIs for doing that. Seems like an excellent idea, in fact. Again, my concern is that the exception-throwing behavior is error-prone, and worse yet that we have existing uses of the API that make certain assumptions that the behavior will break. If this were a brand-new API I could perhaps be convinced to do the exception thing, since that's just how it would be. I'm really worried about deploying that sort of thing into the existing environment, though. -Boris
