[Bug 11157] New: carasen
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11157 Summary: carasen Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Web Database (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: carase...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 11157] carasen
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11157 Tab Atkins Jr. jackalm...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jackalm...@gmail.com Resolution||INVALID --- Comment #2 from Tab Atkins Jr. jackalm...@gmail.com 2010-10-28 14:06:16 UTC --- Not hot. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote: But both approaches would reliably throw exceptions if a client got things wrong. See, there's the thing. Neither approach is all that reliable (even to the point of throwing sometimes but not others for identical code), and access is more prone to issues where which code the exception is thrown in is not consistent (including being timing-dependent), if multiple listeners are involved. Do people really think that action at a distance situations where pulling slightly and innocuously on one bit of a system perturbs other parts of the system in fatal ways are acceptable for the web platform? They're the sort of things that one avoids as much as possible in other systems, but this thread is all about proposing such behaviors for the web platform... I don't think that kind of approach is good design. When design APIs (especially for a platform as widely used as the Web), it's better to design them with fewer possible ways to use them wrong. Making a subtle mistake impossible by design is better than throwing an exception when you make that mistake. I realize memory use is a concern and it's definitely easy to use too much memory in all sorts of ways. But a fragile API is an even bigger problem, in my opinion. Regards, Maciej
Feedback requested on returning null/void or throwing an exception
Hi All,
We've came across a situation in the RDFa API which could do with some
input from the webapps group, primarily on the WebIDL side of things.
We have the following interface:
[NoInterfaceObject]
interface TypedLiteral : RDFNode {
readonly attribute stringifier DOMString value;
readonly attribute IRI type;
any valueOf ();
};
If a converter is registered with the API for the specific `type` then
valueOf() returns the native type (for instance Date in the case of
xsd:dateTime).
We are currently looking for input on what valueOf() should return when
there is no converter registered. Choices we're looking at are:
1: unconverted value
2: throw an exception
3: return null
4: return void
1 and 2 aren't really any option tbh - 3 I prefer, 4 another member of
the WG prefers, but primarily we're looking for best practise in this
scenario, and whether 4 is even an option.
Best and TIA,
Nathan
[XHR2] why have an asBlob attribute at all?
I'm late to this asBlob vs. responseType party, but I tend to agree with Boris's initial response: 4) Make things easy to use for authors; that means supporting responseText and responseArrayBuffer, with access to both on the same XHR object without weird restrictions and without clairvoyance required on the part of the author. If UAs feel that they don't want to keep both copies of the data in memory on a permanent basis, they can optimize this by dropping the responseText (on a timer or via a low-memory detection mechanism, or in various other ways) and regenerating it from the raw bytes as needed. In fact, I'd go further and ask why the blob case needs to be special cased at all.The bytes are stored somewhere. Returning them as a blob doesn't seem any harder than returning them as an ArrayBuffer. This is not a rhetorical question. As a web developer reading the XHR2 spec, I do not get why there is one type of response that I have to request specially. Searching through the archives just now I found this from June: XHR will have a responseBlob property. In order to signal the XHR that it should spool to disk and supply responseBlob, a flag must be set before send() is called. I know that Blobs are an outgrowth of the File API, but won't many Blobs (created by BlobBuilders, for example) be in-memory objects rather than on-disk objects? And shouldn't the decision about whether to spool a response to disk or not be implementation-dependent?It seems to me that an implementation might want to take a look at the Content-Length header and spool any response 1M, for example to disk and then memory map it to make it look like it is in memory. This might be a good strategy even if the response is going to be decoded into text rather than treated as a blob. It seems to me that the Blob case is really the primordial response type. responseArrayBuffer, responseText and responseXML are views of the underlying Blob. So why not just get rid of asBlob altogether? (Probably because I'm missing something fundamental about the nature of Blobs... I'd love to know what it is!) David Flanagan
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
I'm not sure I completely understand the use case with the cross-site scripts. Are we talking about a situation where one library initiates the XHR and another library's event listener receives the data, where it's not aware if the data is actually text or a binary payload? I can understand the concerns about throwing an exception and how hard it might be to debug. But isn't this a problem case also if we don't throw an exception and the data is interpreted as text when it's really binary or vice versa? After all, if you access responseText and the data is really binary, then it will be converted to some bogus text string which could cause some pretty insidious bugs. Please forgive me if I misunderstand, which may very well be the case :) Chris On Thu, Oct 28, 2010 at 10:33 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote: But both approaches would reliably throw exceptions if a client got things wrong. See, there's the thing. Neither approach is all that reliable (even to the point of throwing sometimes but not others for identical code), and access is more prone to issues where which code the exception is thrown in is not consistent (including being timing-dependent), if multiple listeners are involved. Do people really think that action at a distance situations where pulling slightly and innocuously on one bit of a system perturbs other parts of the system in fatal ways are acceptable for the web platform? They're the sort of things that one avoids as much as possible in other systems, but this thread is all about proposing such behaviors for the web platform... I don't think that kind of approach is good design. When design APIs (especially for a platform as widely used as the Web), it's better to design them with fewer possible ways to use them wrong. Making a subtle mistake impossible by design is better than throwing an exception when you make that mistake. I realize memory use is a concern and it's definitely easy to use too much memory in all sorts of ways. But a fragile API is an even bigger problem, in my opinion. Regards, Maciej
Re: Feedback requested on returning null/void or throwing an exception
Hi Nathan.
Nathan:
We have the following interface:
[NoInterfaceObject]
interface TypedLiteral : RDFNode {
readonly attribute stringifier DOMString value;
readonly attribute IRI type;
any valueOf ();
};
If a converter is registered with the API for the specific `type`
then valueOf() returns the native type (for instance Date in the
case of xsd:dateTime).
We are currently looking for input on what valueOf() should return
when there is no converter registered. Choices we're looking at are:
1: unconverted value
2: throw an exception
3: return null
4: return void
What are the unconverted values? If they’re not values in the IDL value
space, you’ll need to define some sort of conversion.
1 and 2 aren't really any option tbh - 3 I prefer, 4 another member
of the WG prefers, but primarily we're looking for best practise in
this scenario, and whether 4 is even an option.
Well, the operation is defined to return “any”, so you have to return
something. You could define it so that undefined is returned in ES.
Could “null” ever be a converted value?
I guess I would need to understand the problem space a bit better.
BTW, I guess it is deliberate that you have a function named valueOf on
there, so that you get funky behaviour when you use these objects in
arithmetic expressions in ES?
It *may* be confusing. Since the TypedLiteral prototype will have both
a toString and a valueOf, you can get situations where converting the
object to a string by passing it to the String constructor function
results in different value from concatenating '' on to it:
var p = { toString: function() { return 'a string' },
valueOf: function() { return 123 } };
var a = Object.create(p);
alert(String(a)); // alerts a string
alert(a + ''); // alerts 123
--
Cameron McCormack ≝ http://mcc.id.au/
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
I think a good rule for any web API is that the user's needs come before the author's needs. In this case there is a very large amount of content out there today that uses XMLHttpRequest to download data, sometimes significant amounts of data, and that use .responseText exclusively to access that data. Adding a new feature to the API that causes this use case to be worse for the user (by requiring it to use twice as much memory) seems like a clear non-starter to me - that would be putting authors before users. Would you accept a new DOM feature that required each node to use twice as much memory? The memory use and heap pressure caused by XHR has been an issue for Chrome in the past and our current implementation is pretty carefully tuned to not preserve extra copies of any data, not perform redundant text decoding operations, and to interact well with the JavaScript engine. It's true that it might be a convenient API for authors to provide the response data in all formats at all times. However this would not benefit any content deployed on the web right now that uses responseText exclusively and would make the user experience unambiguously worse. Instead we need to find a way to provide new capabilities in a way that does not negatively impact what is already out there on the web. Within this space I'm sure there are several good solutions. As another general note, I think it's rather unfortunate how many different responsibilities are currently handled by XMLHttpRequest. It's the networking primitive of the web, but it also provides text decoding capabilities and XML parsing (of all things) for historical reasons. It's a very awkward API and it should be gaining fewer responsibilities over time, not more. Ideally an author should be able to use XHR just to take care of networking and for other APIs to provide other new capabilities. For example, it should be possible to take a sequence of raw bytes off the network from XHR and interpret some subset of the sequence as UTF-8 text and the rest as audio data. This would be possible using some form of .responseArrayBuffer and ArrayBufferViews if text decoding was exposed as its own API rather than only as a feature of XMLHttpRequest. This is somewhat pie-in-the-sky right now, but I think it's important to keep in mind as a longer term goal. I'm not convinced that we need to worry overly much about legacy libraries mishandling .responseArrayBuffer. Any code that tries to handle .responseArrayBuffer will by definition be new code and will have to deal with the API whatever that ends up being. Code that wants to use .responseText can continue to do so, but it won't be able to use .responseArrayBuffer as well. Seems like a pretty simple situation as such things go. - James
Re: [XHR2] why have an asBlob attribute at all?
On 10/28/10 5:22 PM, David Flanagan wrote: In fact, I'd go further and ask why the blob case needs to be special cased at all. The bytes are stored somewhere. Returning them as a blob doesn't seem any harder than returning them as an ArrayBuffer. David, the issue is that if you make a request for a 4GB resource and ask for it as an array buffer and you're on a 32-bit system, the only thing the browser can do is throw an out of memory exception. On the other hand, if you access the same response as a blob, the browser can let you do that; you just won't be able to get it all into a single JS string. So there are definitely use cases for being able to access as a Blob. I know that Blobs are an outgrowth of the File API, but won't many Blobs (created by BlobBuilders, for example) be in-memory objects rather than on-disk objects? I believe BlobBuilder can stick the data anywhere it wants. And shouldn't the decision about whether to spool a response to disk or not be implementation-dependent? It is, yes. But we still need an API that doesn't force the response into memory in its entirety. and then memory map it to make it look like it is in memory. That doesn't help for the truly large responses; the OS won't let you memory map them in its entirety... (Probably because I'm missing something fundamental about the nature of Blobs... I'd love to know what it is!) The key part with a blob is that you can access parts of it without forcing the whole thing into the process's address space. -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On 10/28/10 5:40 PM, Chris Rogers wrote: I'm not sure I completely understand the use case with the cross-site scripts. Are we talking about a situation where one library initiates the XHR and another library's event listener receives the data, where it's not aware if the data is actually text or a binary payload? The cross-site script use case I was thinking is something simple like allowing some whitelisted sites to request gmail attachments for a given user. You don't necessarily know what you're getting until the data starts coming in. I can understand the concerns about throwing an exception and how hard it might be to debug. The concern in the cross-site case is that you're less likely than in the same-site case to know before you start getting the data what data to expect, since the whole point of cross-site is that you don't control the data you're getting. But isn't this a problem case also if we don't throw an exception and the data is interpreted as text when it's really binary or vice versa? I'm not sure there's the dichotomy is as sharp as you make it out, but in any case, the right way to access the data can be based on the content-type the data reports, yes? It's just that this decision can't be made at open() time. After all, if you access responseText and the data is really binary, then it will be converted to some bogus text string Sure. Though if the data is really text you may meaningfully want to access the actual bytes sent. -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Thu, Oct 28, 2010 at 10:33 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 27, 2010, at 5:36 PM, Boris Zbarsky wrote: But both approaches would reliably throw exceptions if a client got things wrong. See, there's the thing. Neither approach is all that reliable (even to the point of throwing sometimes but not others for identical code), and access is more prone to issues where which code the exception is thrown in is not consistent (including being timing-dependent), if multiple listeners are involved. Do people really think that action at a distance situations where pulling slightly and innocuously on one bit of a system perturbs other parts of the system in fatal ways are acceptable for the web platform? They're the sort of things that one avoids as much as possible in other systems, but this thread is all about proposing such behaviors for the web platform... I don't think that kind of approach is good design. When design APIs (especially for a platform as widely used as the Web), it's better to design them with fewer possible ways to use them wrong. Making a subtle mistake impossible by design is better than throwing an exception when you make that mistake. I realize memory use is a concern and it's definitely easy to use too much memory in all sorts of ways. But a fragile API is an even bigger problem, in my opinion. Personally I like the proposed responseType solution. I agree that it has a downside in that it doesn't allow figuring out the type as data starts coming in. However I think this is a much less common case then knowing the type before the request is made. Both for the case when downloading from your own site as when downloading cross-origin. It makes sense to me that this is the common case too as it makes sense that the author is loading a particular set of information, which is presented in a particular format. 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 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. Maciej pointed out one good example of when that can happen with authors using responseText.length to measure progress. We already have the situation of too much memory use in a couple of cases today. The simplest example is if someone uses XMLHttpRequest the way the name actually encourages, downloading an XML file. In that case we need to store both the parsed Document as well as the unparsed string (or binary data) in memory until the XHR is GCed. We also have the situation in that data is continuously concatenated to the end of the already downloaded data. For users that can handle progressive handling of the downloaded content, keeping all the so-far-downloaded data in memory is pure waste. (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. This is behavior that we can improve but never make perfect). Another problem we currently have, which Darin pointed out, is the kitchensink issue. Currently XMLHttpRequest deals both with the network request, as well as parsing the response. Having a mode parameter, like responseType, which controls how to treat the response has the potential to address many of these issues. For the case when it's known what type of response is expected this seems to work very well. So you could set .responseType = document to have the result parsed into a document, .responseType = text to parse into text, .responseType = binary to parse into a ArrayBuffer, and .responseType = blob to stream to a blob. We can even add .responseType = stream to have the result as a Stream object which can be used for various streaming solutions. I'm struggling a bit with what an ideal API looks like to support the case of downloading something of an unknown type. For the case of the Content-Type header containing enough information we could have an event which is fired as soon as all header data is available, but before any of the response body has been processed. At that point the .responseType property could still be allowed to be modified. 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. Another, somewhat hacky, solution is to say that it's allowed to change .responseType from binary to any other value at any point. At that point the XHR object would reparse the contents using that type. However I'd rather prefer to move parsing into various types out from the XHR object. So
Re: Feedback requested on returning null/void or throwing an exception
Hi Cameron,
Thanks for your reply, comments in-line from here:
Cameron McCormack wrote:
Nathan:
We have the following interface:
[NoInterfaceObject]
interface TypedLiteral : RDFNode {
readonly attribute stringifier DOMString value;
readonly attribute IRI type;
any valueOf ();
};
If a converter is registered with the API for the specific `type`
then valueOf() returns the native type (for instance Date in the
case of xsd:dateTime).
We are currently looking for input on what valueOf() should return
when there is no converter registered. Choices we're looking at are:
1: unconverted value
2: throw an exception
3: return null
4: return void
What are the unconverted values? If they’re not values in the IDL value
space, you’ll need to define some sort of conversion.
The values can be anything which is valid in the object position of an
rdf triple, which is anything tbh, normally one of the xsd:types though.
To handle conversion the API has a core set of TypedLiteralConverters
implementers must implement for things like dataTime/numerics/boolean
etc - however people can also register there own TypedLiteralConverters
to support more types (for instance base64 encoded binary). A
TypedLiteralConverter is a just a callback that given a string value and
for a specific string-iri type will do the conversion to native js type
or something else which the user has implemented.
The toValue method implementation checks to see if a typed literal
converter is registered for the given .type and then passes in the .type
and .value (as a string) to get the converted/native type back.
Thus, the any definition is because it entirely depends on the .type as
to what is returned.
This specific toValue method on this interface may be dropped, however
the functionality will still be on another interface, so perhaps best to
focus on that.
Given a function:
any convertType( in DOMString value , in DOMString type );
where value is a string of say 1234 and type is an IRI for say
xsd:integer - and where (critically) a function to convert the specified
type may not be known, what should the return be? null, void/undefined
or other?
I imagine this isn't the most common use-case, but it is required
functionality we have to specify as part of the API.
In reply generally to everything below, the names aren't set in stone,
nor the interface on which the functionality will be exposed, but
regardless of where we put it and other details aside, it's the specific
situation above that's causing the questions / being a pita.
1 and 2 aren't really any option tbh - 3 I prefer, 4 another member
of the WG prefers, but primarily we're looking for best practise in
this scenario, and whether 4 is even an option.
Well, the operation is defined to return “any”, so you have to return
something. You could define it so that undefined is returned in ES.
Could “null” ever be a converted value?
We're debating this at the minute, one person has said yes null could
be a converted value for them, which means yes it could be - however
it's also been suggested that null is a single value thus, we could
disallow it / reserve it, because a TypedLiteral with a type of
http://example.org/types/null; could only ever be null, thus detected
and specified without needing any conversion functionality.
I guess I would need to understand the problem space a bit better.
Hopefully the above clarifies, if not just let me know - can easily pull
the time to sort this out whenever you're free, via mailing list, irc or
other.
BTW, I guess it is deliberate that you have a function named valueOf on
there, so that you get funky behaviour when you use these objects in
arithmetic expressions in ES?
It *may* be confusing. Since the TypedLiteral prototype will have both
a toString and a valueOf, you can get situations where converting the
object to a string by passing it to the String constructor function
results in different value from concatenating '' on to it:
var p = { toString: function() { return 'a string' },
valueOf: function() { return 123 } };
var a = Object.create(p);
alert(String(a)); // alerts a string
alert(a + ''); // alerts 123
Good point, I have no idea why valueOf was originally chosen TBH as I'm
new-ish to the working group, however I'm sure it could be changed /
renamed or even removed to avoid confusion.
Thanks again for your reply thus far, much appreciated,
Nathan
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Thu, Oct 28, 2010 at 8:37 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/28/10 9:11 PM, James Robinson wrote: I think a good rule for any web API is that the user's needs come before the author's needs. And the author's before the implementor's, right? OK, let's take that as given. In this case there is a very large amount of content out there today that uses XMLHttpRequest to download data, sometimes significant amounts of data, and that use .responseText exclusively to access that data. Agreed. Adding a new feature to the API that causes this use case to be worse for the user (by requiring it to use twice as much memory) In a particular simplistic implementation, right? seems like a clear non-starter to me - that would be putting authors before users. More precisely, putting authors before implementors, seems to me... Would you accept a new DOM feature that required each node to use twice as much memory? That _required_? Probably not. But responseArrayBuffer doesn't require twice as much memory if you're willing to make other tradeoffs (e.g. sync read in the bytes from non-RAM storage) in some situations. The memory use and heap pressure caused by XHR has been an issue for Chrome in the past and our current implementation is pretty carefully tuned to not preserve extra copies of any data, not perform redundant text decoding operations, and to interact well with the JavaScript engine. I understand that. It's true that it might be a convenient API for authors to provide the response data in all formats at all times. OK, we agree on that. However this would not benefit any content deployed on the web right now that uses responseText exclusively and would make the user experience unambiguously worse. Seems to me that if all you care about is the user experience being no worse for content that only uses responseText you can just dump the raw bytes to disk and not worry about the slowness of reading them back... You could also have a way for authors to hint to you to NOT thus dump them to disk (e.g. a boolean they set before send(), which makes you hold on to the bytes in memory instead, but doesn't cause any weird exception-throwing behavior). Is there any benefit in pursuing that line of thought or do you consider it a non-starter? If the latter, why? Are we talking about ArrayBuffer here or Blob? It's never acceptable to block javascript on a synchronous disk access, so storing data on disk that is synchronously accessible from javascript would be a non-starter for Chrome. Note how the Blob and various File APIs are very careful to not every block javascript on synchronous access to file-backed data. - James Instead we need to find a way to provide new capabilities in a way that does not negatively impact what is already out there on the web. Ideally, yes. In practice, new capabilities are provided by various specs all the time that negatively impact performance, sometimes even when carefully optimized around. Such is life. Within this space I'm sure there are several good solutions. OK, would those be the ones listed near the beginning of this thread? As another general note, I think it's rather unfortunate how many different responsibilities are currently handled by XMLHttpRequest. Sure, we all agree on that. We're somewhat stuck with it, sadly. I'm not convinced that we need to worry overly much about legacy libraries mishandling .responseArrayBuffer. Any code that tries to handle .responseArrayBuffer will by definition be new code and will have to deal with the API whatever that ends up being. So what you're saying is that code that wants to use .responseArrayBuffer can't be using jquery. That seems like a somewhat high adoption bar for .responseArrayBuffer, no? Code that wants to use .responseText can continue to do so, but it won't be able to use .responseArrayBuffer as well. Seems like a pretty simple situation as such things go. I really have the sense I'm not getting through here. You seem to be assuming that a single entity is responsible for all the code that runs on the page. That may be the case at Google. It's commonly NOT the case elsewhere. So things that break some code due to things that some other code did that seemed entirely reasonable are something we should be trying to not introduce if we can avoid them. I'm happy to try to find a better solution here if you think there are insurmountable implementation difficulties in supporting the simple and author-intuitive API. I'm happy to complicate the API somewhat if that makes it more implementable. I'm not so happy to make it fragile, though. -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On 10/29/10 12:15 AM, James Robinson wrote: Are we talking about ArrayBuffer here or Blob? The former. It's never acceptable to block javascript on a synchronous disk access Why? Other questions to consider: 1) Why is it ok to block it on a synchronous disk access due to being paged in but not to block on a synchronous disk access due to reading a file descriptor? Or is the former not acceptable too? 2) Why is it ok to block on a synchronous disk access due to being paged in but not to block on a synchronous disk access due to having the backing store for your mmap moved from disk to RAM? Or is the latter acceptable? But if we posit this, how author-hostile would an API that provides asynchronous access to the byte buffer, with a callback when it's available, be? Would you be willing to implement that in Chrome? -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Oct 28, 2010, at 9:41 PM, Boris Zbarsky wrote: On 10/29/10 12:15 AM, James Robinson wrote: Are we talking about ArrayBuffer here or Blob? The former. It's never acceptable to block javascript on a synchronous disk access Why? Other questions to consider: 1) Why is it ok to block it on a synchronous disk access due to being paged in but not to block on a synchronous disk access due to reading a file descriptor? Or is the former not acceptable too? These days, not every end-user system can be assumed to have paging. Regards, Maciej
[Bug 11164] New: There is no way to get from an error event to other objectStores
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11164 Summary: There is no way to get from an error event to other objectStores Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org If inserting data into an objectStore fails, and an error event is dispatched, it is possible to get to the objectStore where the insertion failed, but from there you can't get to the transaction and thus not to the other objectStores. We should either add .transaction to error events (possibly by mucking with the inheritance chain for IDBTransactionEvent), or by adding .transaction to IDBObjectStore. Possibly we should do both. Similarly, we might want to add .objectStore on IDBIndex. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR2] why have an asBlob attribute at all?
On 10/28/2010 06:24 PM, Boris Zbarsky wrote: On 10/28/10 5:22 PM, David Flanagan wrote: In fact, I'd go further and ask why the blob case needs to be special cased at all. The bytes are stored somewhere. Returning them as a blob doesn't seem any harder than returning them as an ArrayBuffer. David, the issue is that if you make a request for a 4GB resource and ask for it as an array buffer and you're on a 32-bit system, the only thing the browser can do is throw an out of memory exception. On the other hand, if you access the same response as a blob, the browser can let you do that; you just won't be able to get it all into a single JS string. Thanks for the explanation, Boris. The L in Blob is an order of magnitude larger than anything I was imagining. Now I understand why both Blobs and ArrayBuffer are required. I still don't get, however, why the API needs distinct blob/non-blob modes. Why not do it like this: - The implementation decides whether to store the response in a file or not based on its own knowledge of the Content-Length and of the system's hardware. (And perhaps the developer can set some kind of reallyBig flag as a hint that the implementation should consider saving the response to disk.) - The response body is always available through responseBlob. No special asBlob flag is required. - If the response is too big to fit in memory, then accessing responseText, responseArrayBuffer or responseXML will throw an out-of-memory exception. This is what would happen if you naively tried to use the FileReader interface on the un-sliced Blob, so why can't that happen here? With the API as it is now, a web developer who wants to download a gigantic chunk of data has to know in advance to use a blob to avoid the possibility of out-of-memory errors. They have to put their XHR object into a special asBlob mode in order to do so. And once they ar in that mode if they try to use responseText or responseArrayBuffer, they're guaranteed to get a INVALID_STATE_ERR exception at runtime. With my proposal, the developer still has to know in advance that they probably ought to use a blob. But they don't have to set a special flag to do it. And if they do use responseText or responseArrayBuffer, they might get an out-of-memory error at runtime, but there's also a decent chance that things will just work (maybe with some disk swapping slowing things down a bit). 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. David
