Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
Hi Chris. I like the efficiency of this approach. And I agree with your premise that a developer will probably only want one type of data (raw, text, or XML) per request, and not more than one. My biggest concern with this idea is that there's nothing obvious about the API pattern of three properties -- .responseText, .responseXML, and .responseArrayBuffer -- that makes clear that accessing one should prohibit access to the others. I wonder if there's a good way to make this clearer. Maybe the API should require the programmer to specify in advance what type of data he/she will ask for. For example, an extra responeType parameter passed to open. The default behavior would be the values currently supported, but you could opt into something specific for extra safety/performance, and new types of data: request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); Geoff On Oct 22, 2010, at 4:47 PM, Chris Rogers wrote: A few weeks ago I brought up the idea of implementing the responseArrayBuffer attribute for XHR: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute One of the concerns was that it might require double the memory usage since the raw bytes would have to be accumulated along with the decoded text as it's being built up. One possible solution which I've been discussing with James Robinson and Ken Russell is to defer decoding the text, and instead buffer the raw data as it comes in. If there's any access to responseText (or responseXML), then the buffered data can be decoded into text at that time, and the buffered raw data discarded. If that case happens, then from that point on no raw data buffering would happen and the text would be accumulated as it is right now. Otherwise, if responseText is never accessed then the raw data continues to buffer until it's completely loaded. Then an access to responseArrayBuffer can easily convert the raw bytes to an ArrayBuffer. The idea is that once responseText or responseXML is accessed, then it would no longer be possible to access responseArrayBuffer (an exception would be thrown). Conversely, once responseArrayBuffer is accessed, then it would no longer be possible to use responseText or responseXML (an exception would be thrown). This approach does seem a little strange because of the mutually exclusive nature of the access. However, it seems that it would be hard to come up for a reasonable use case where both the raw bytes *and* the text would be needed for the same XHR. How does this sound as an approach? Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
The solution for .responseBlob was to add an .asBlob attribute that would need to be set to true before calling .send(). We could do the same for .responseArrayBuffer. -Darin On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote: Hi Chris. I like the efficiency of this approach. And I agree with your premise that a developer will probably only want one type of data (raw, text, or XML) per request, and not more than one. My biggest concern with this idea is that there's nothing obvious about the API pattern of three properties -- .responseText, .responseXML, and .responseArrayBuffer -- that makes clear that accessing one should prohibit access to the others. I wonder if there's a good way to make this clearer. Maybe the API should require the programmer to specify in advance what type of data he/she will ask for. For example, an extra responeType parameter passed to open. The default behavior would be the values currently supported, but you could opt into something specific for extra safety/performance, and new types of data: request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); Geoff On Oct 22, 2010, at 4:47 PM, Chris Rogers wrote: A few weeks ago I brought up the idea of implementing the responseArrayBuffer attribute for XHR: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute One of the concerns was that it might require double the memory usage since the raw bytes would have to be accumulated along with the decoded text as it's being built up. One possible solution which I've been discussing with James Robinson and Ken Russell is to defer decoding the text, and instead buffer the raw data as it comes in. If there's any access to responseText (or responseXML), then the buffered data can be decoded into text at that time, and the buffered raw data discarded. If that case happens, then from that point on no raw data buffering would happen and the text would be accumulated as it is right now. Otherwise, if responseText is never accessed then the raw data continues to buffer until it's completely loaded. Then an access to responseArrayBuffer can easily convert the raw bytes to an ArrayBuffer. The idea is that once responseText or responseXML is accessed, then it would no longer be possible to access responseArrayBuffer (an exception would be thrown). Conversely, once responseArrayBuffer is accessed, then it would no longer be possible to use responseText or responseXML (an exception would be thrown). This approach does seem a little strange because of the mutually exclusive nature of the access. However, it seems that it would be hard to come up for a reasonable use case where both the raw bytes *and* the text would be needed for the same XHR. How does this sound as an approach? Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
On Oct 25, 2010, at 12:22 PM, Darin Fisher wrote: The solution for .responseBlob was to add an .asBlob attribute that would need to be set to true before calling .send(). We could do the same for .responseArrayBuffer. -Darin On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote: Hi Chris. I like the efficiency of this approach. And I agree with your premise that a developer will probably only want one type of data (raw, text, or XML) per request, and not more than one. My biggest concern with this idea is that there's nothing obvious about the API pattern of three properties -- .responseText, .responseXML, and .responseArrayBuffer -- that makes clear that accessing one should prohibit access to the others. I wonder if there's a good way to make this clearer. Maybe the API should require the programmer to specify in advance what type of data he/she will ask for. For example, an extra responeType parameter passed to open. The default behavior would be the values currently supported, but you could opt into something specific for extra safety/performance, and new types of data: request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then: any responseObject(); DOMString responseType(); That would allow us to expand the types supported without any additional API. We'd need to support the current API calls for backward compatibility. But now seems like a good time to plan for the future. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
passing undefined as the 4th and 5th arguments seems pretty clunky to me. Since, we already have an asBlob attribute, then asArrayBuffer like Darin suggests seems like it might be better. However, then we can get into cases where both asBlob and asArrayBuffer are set, and this problem would get even worse as new types are added. So, an attribute called responseType might be a good solution. This would be instead of passing it as an argument to open(), and instead of having an asBlob attribute. This approach seems the cleanest to me, and I'll propose it to the appropriate standards group. Chris On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov a...@webkit.org wrote: 25.10.2010, в 12:34, Chris Marrin написал(а): request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then: Note that open() has username and password as its 4th and 5th arguments. So, you'd have to call it like request.open(GET, data.xml, true, undefined, undefined, Bytes); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
How do you address the discoverability issue that I raised? asBlob and asArrayBuffer have the benefit of being detectable at runtime. but, a settable responseType does not support detection of supported values. -Darin On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers crog...@google.com wrote: passing undefined as the 4th and 5th arguments seems pretty clunky to me. Since, we already have an asBlob attribute, then asArrayBuffer like Darin suggests seems like it might be better. However, then we can get into cases where both asBlob and asArrayBuffer are set, and this problem would get even worse as new types are added. So, an attribute called responseType might be a good solution. This would be instead of passing it as an argument to open(), and instead of having an asBlob attribute. This approach seems the cleanest to me, and I'll propose it to the appropriate standards group. Chris On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov a...@webkit.orgwrote: 25.10.2010, в 12:34, Chris Marrin написал(а): request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then: Note that open() has username and password as its 4th and 5th arguments. So, you'd have to call it like request.open(GET, data.xml, true, undefined, undefined, Bytes); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
True, it's not as simple as checking for the existence of an attribute, but it could throw an exception. It seems like having both asBlob and asArrayBuffer also creates the possibility of bad combinations of settings which could get confusing, especially if more types are added in the future. Chris On Mon, Oct 25, 2010 at 3:04 PM, Darin Fisher da...@chromium.org wrote: How do you address the discoverability issue that I raised? asBlob and asArrayBuffer have the benefit of being detectable at runtime. but, a settable responseType does not support detection of supported values. -Darin On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers crog...@google.com wrote: passing undefined as the 4th and 5th arguments seems pretty clunky to me. Since, we already have an asBlob attribute, then asArrayBuffer like Darin suggests seems like it might be better. However, then we can get into cases where both asBlob and asArrayBuffer are set, and this problem would get even worse as new types are added. So, an attribute called responseType might be a good solution. This would be instead of passing it as an argument to open(), and instead of having an asBlob attribute. This approach seems the cleanest to me, and I'll propose it to the appropriate standards group. Chris On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov a...@webkit.orgwrote: 25.10.2010, в 12:34, Chris Marrin написал(а): request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then: Note that open() has username and password as its 4th and 5th arguments. So, you'd have to call it like request.open(GET, data.xml, true, undefined, undefined, Bytes); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XHR responseArrayBuffer attribute: possible implementation
You could aid discoverability -- and programming -- by providing a set of enumerated constants on the XHR constructor, much like the Node constructor provides for NodeTypes. Another option would be to throw an exception when setting responseType to an unsupported value. Geoff On Oct 25, 2010, at 3:04 PM, Darin Fisher wrote: How do you address the discoverability issue that I raised? asBlob and asArrayBuffer have the benefit of being detectable at runtime. but, a settable responseType does not support detection of supported values. -Darin On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers crog...@google.com wrote: passing undefined as the 4th and 5th arguments seems pretty clunky to me. Since, we already have an asBlob attribute, then asArrayBuffer like Darin suggests seems like it might be better. However, then we can get into cases where both asBlob and asArrayBuffer are set, and this problem would get even worse as new types are added. So, an attribute called responseType might be a good solution. This would be instead of passing it as an argument to open(), and instead of having an asBlob attribute. This approach seems the cleanest to me, and I'll propose it to the appropriate standards group. Chris On Mon, Oct 25, 2010 at 12:45 PM, Alexey Proskuryakov a...@webkit.org wrote: 25.10.2010, в 12:34, Chris Marrin написал(а): request.open(GET, data.xml, true, Text); request.open(GET, data.xml, true, XML); request.open(GET, data.xml, true, Bytes); I'd sure like to try to avoid an explosion in the API. I like Geoff's suggestion of specifying the type of request in open(). Seems like the best API would be to have Geoff's API and then: Note that open() has username and password as its 4th and 5th arguments. So, you'd have to call it like request.open(GET, data.xml, true, undefined, undefined, Bytes); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XHR responseArrayBuffer attribute: possible implementation
A few weeks ago I brought up the idea of implementing the responseArrayBuffer attribute for XHR: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute One of the concerns was that it might require double the memory usage since the raw bytes would have to be accumulated along with the decoded text as it's being built up. One possible solution which I've been discussing with James Robinson and Ken Russell is to defer decoding the text, and instead buffer the raw data as it comes in. If there's any access to responseText (or responseXML), then the buffered data can be decoded into text at that time, and the buffered raw data discarded. If that case happens, then from that point on no raw data buffering would happen and the text would be accumulated as it is right now. Otherwise, if responseText is never accessed then the raw data continues to buffer until it's completely loaded. Then an access to responseArrayBuffer can easily convert the raw bytes to an ArrayBuffer. The idea is that once responseText or responseXML is accessed, then it would no longer be possible to access responseArrayBuffer (an exception would be thrown). Conversely, once responseArrayBuffer is accessed, then it would no longer be possible to use responseText or responseXML (an exception would be thrown). This approach does seem a little strange because of the mutually exclusive nature of the access. However, it seems that it would be hard to come up for a reasonable use case where both the raw bytes *and* the text would be needed for the same XHR. How does this sound as an approach? Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
