Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, Feb 28, 2012 at 7:11 AM, Simon Pieters sim...@opera.com wrote: On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote: On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan aranganat...@mozilla.comwrote: Simon, Is the relevant part of HTML sufficient to refer to? http://dev.w3.org/html5/spec/Overview.html#utf-8 I was thinking of If the data argument has any unpaired surrogates, then throw a SyntaxError exception.. http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#dom-websocket-send That defines decoding UTF-8 to Unicode strings. You need the reverse. Using a replacement scheme like UTF-8 decoding, instead of a hard exception, seems more consistent with how encodings in general are handled. Otherwise, you'll end up with bugs in code if, for example, people paste in unpaired surrogates (Firefox allows this, last I checked), Maybe unpaired surrogates should be converted to U+FFFD on paste. Are there other cases? causing unexpected exceptions in code. Instead, just convert them to U+FFFD, which gives much more graceful error handling for such a rare case that most people will never handle explicitly. If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to U+FFFD them in APIs. If the only way to get them is a JS escape, then an exception seems OK. People use JS strings to handle binary data. This is something that has worked since the dawn of JS and is something that I believe is defined to work in recent ECMAScript specs. I don't think that we can start restricting that and try to enforce that JS-strings always contain valid UTF16. So I think our only option is to make all APIs which does UTF16-UTF8 conversion explicitly define how to deal with invalid surrogates. My preference would be to deal with them by encoding them to U+FFFD for the same reason that we let the HTML parser do error recovery rather than XML-style draconian error handling. / Jonas
[widgets] Request for a CFC about Widget URI and Updates
I think it might be time to have a CFC to propose moving Widget URI and Widget Updates to WG Notes. Although both specs have gotten implemented, I'm not interested in continuing the work unless I have industry backing. Kind regards, Marcos
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote: If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense to U+FFFD them in APIs. If the only way to get them is a JS escape, then an exception seems OK. People use JS strings to handle binary data. This is something that has worked since the dawn of JS and is something that I believe is defined to work in recent ECMAScript specs. I don't think that we can start restricting that and try to enforce that JS-strings always contain valid UTF16. Right. So I think our only option is to make all APIs which does UTF16-UTF8 conversion explicitly define how to deal with invalid surrogates. Sure, I don't suggest we leave it undefined. My preference would be to deal with them by encoding them to U+FFFD for the same reason that we let the HTML parser do error recovery rather than XML-style draconian error handling. I'm not really opposed to making APIs use U+FFFD instead of exception, but I'm not entirely convinced, either. If people use binary data in strings and want to use them in these APIs, U+FFFDing lone surrogates is going to silently scramble their data. Why is this better than throwing an exception? -- Simon Pieters Opera Software
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, Feb 28, 2012 at 1:57 PM, Simon Pieters sim...@opera.com wrote: My preference would be to deal with them by encoding them to U+FFFD for the same reason that we let the HTML parser do error recovery rather than XML-style draconian error handling. I'm not really opposed to making APIs use U+FFFD instead of exception, but I'm not entirely convinced, either. If people use binary data in strings and want to use them in these APIs, U+FFFDing lone surrogates is going to silently scramble their data. Why is this better than throwing an exception? I'm not so much worried that people will store binary and then attempt to send it as text. I'm more worried people will do things like cut up a string into parts and send the parts separately, or have bugs in some search'n'replace code which could result in invalid surrogates being created and then send the resulting strings over a websocket. The error conditions would be very intermittent since it would entirely depend on the data (which could be user provided) which is being processed and so might not reproduce easily for the developer. I agree that it scrambles the data. But no more than the HTML parser error recovery does. And if an unexpected exception is thrown then the result is likely dataloss which is not obviously better than scrambling part of the data. / Jonas
Re: [IndexedDB] Numeric constants vs enumerated strings
On Tue, 28 Feb 2012 01:50:22 +0100, Israel Hilerio isra...@microsoft.com wrote: That is certainly one point of view. However, we've been collecting features for a v2 since before June of 2011 [1]. To that effect, we've had several email exchanges between the WG members where we agree to defer work for v2 (see [2], [3], etc.). That tells me that our working group is committed to delivering a v1 version of the spec. Furthermore, the fact that we have a v2 list doesn't invalidate the functionality we defined in v1. For example, there is no reason why the change you are proposing couldn't be introduced in v2 and still be backwards compatible with our legacy code. Yes, you can improve features and you can call that v2 if you want, the point is that once you ship you cannot make backwards incompatible changes. And I think we should here, because Web IDL does not support string constants, strongly advices against numeric constants, and there is ample opportunity for change here. So sure maybe a hundred developers are working with your preview product, but that is nothing compared to what the API will be exposed to in the end. It is our belief based on internal feedback and external partner feedback that the technology will remain un-deployed and in draft form if we continue to make changes like this. Yes it might take a little longer, but Indexed DB has not even been through a Last Call yet and you already want to freeze it? My impression of Indexed DB thus far has been that there has not been that much outside review yet. In any event, aligning it with Web IDL is important. And I hope Indexed DB will move away from DOMStringList too so that can be removed from the platform. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Numeric constants vs enumerated strings
On Tue, Feb 28, 2012 at 5:45 PM, Anne van Kesteren ann...@opera.com wrote: It is our belief based on internal feedback and external partner feedback that the technology will remain un-deployed and in draft form if we continue to make changes like this. Yes it might take a little longer, but Indexed DB has not even been through a Last Call yet and you already want to freeze it? My impression of Indexed DB thus far has been that there has not been that much outside review yet. In any event, aligning it with Web IDL is important. And I hope Indexed DB will move away from DOMStringList too so that can be removed from the platform. Just to be clear. We've all been here long enough to know that Last Call is not what matters, what matters is when implementations ship and when enough content is authored that making incompatible changes will break too much content. This is an argument you yourself has made in other specifications and which I agree is reality we have to live with. That said, I don't think there is enough content out there that would break over this change, which is why I think it's an ok change to make. If you are worried IndexedDB hasn't received enough review, I strongly encourage you to start reviewing. I personally only know of one other bad thing in the API (the fact that the second argument to openCursor is a string rather than a dictionary), but since it's something that can be fixed in the next version I prefer to fix it there. There's also error handling which has been discussed on the mailing list but where the conclusions from that discussion needs to be added to the spec. / Jonas
Re: [IndexedDB] Numeric constants vs enumerated strings
On Tue, 28 Feb 2012 17:56:05 +0100, Jonas Sicking jo...@sicking.cc wrote: Just to be clear. We've all been here long enough to know that Last Call is not what matters, what matters is when implementations ship and when enough content is authored that making incompatible changes will break too much content. This is an argument you yourself has made in other specifications and which I agree is reality we have to live with. I've mostly made that argument when defining legacy features I hope. I do think for new features we should have some explicit call for review when the initial 80% of the work is done. Also, I believe to date no implementation has shipped Indexed DB per specification (that is, without prefix) so that we have this argument at all given that everyone should agree that following Web IDL is important is somewhat surprising to me. If you are worried IndexedDB hasn't received enough review, I strongly encourage you to start reviewing. I don't think I'm necessarily the right person, but I've pointed out that I think DOMStringList and numeric constants should go. I personally only know of one other bad thing in the API (the fact that the second argument to openCursor is a string rather than a dictionary), but since it's something that can be fixed in the next version I prefer to fix it there. I'm not sure I'd call that fixing as authors will have to learn the method works in two different ways, but sure. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]
I think we've been feature complete for a while now. With one exception, which is that some error handling that we've discussed on the list needs to be edited into the spec. Apart from that we have a number of fairly minor uncontroversial fixes (details around generators, order in objectStore/index lists etc), and one more controversial fix (numeric vs. string constants). But these aren't new features by any means. I think the stuff that we have bugs on are mostly things that everyone agree that we can and should fix for v1 since they are mostly defining things that are currently undefined. / Jonas On Tue, Feb 28, 2012 at 6:28 PM, Arthur Barstow art.bars...@nokia.com wrote: Hi All - setting aside this specific issue for the moment, I'd like to step back and try to determine what the group is thinking re getting IDB to feature complete. I note that over two years ago, a pre-LCWD comment period for IDB ended [1] ;-). Additionally, there are 16 open bugs [2] for this spec. It also appears the IDB is getting some relatively broad implementation [3]. As such, what are the plans and schedule to get this spec to feature complete? Besides the issue raised in the head of this thread and the API issue Jonas mentions below, which open bugs are considered must-be-fixed for v1? -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0205.html [2] http://tinyurl.com/Bugz-IndexedDB [3] http://caniuse.com/#feat=indexeddb On 2/28/12 11:56 AM, ext Jonas Sicking wrote: On Tue, Feb 28, 2012 at 5:45 PM, Anne van Kesterenann...@opera.com wrote: It is our belief based on internal feedback and external partner feedback that the technology will remain un-deployed and in draft form if we continue to make changes like this. Yes it might take a little longer, but Indexed DB has not even been through a Last Call yet and you already want to freeze it? My impression of Indexed DB thus far has been that there has not been that much outside review yet. In any event, aligning it with Web IDL is important. And I hope Indexed DB will move away from DOMStringList too so that can be removed from the platform. Just to be clear. We've all been here long enough to know that Last Call is not what matters, what matters is when implementations ship and when enough content is authored that making incompatible changes will break too much content. This is an argument you yourself has made in other specifications and which I agree is reality we have to live with. That said, I don't think there is enough content out there that would break over this change, which is why I think it's an ok change to make. If you are worried IndexedDB hasn't received enough review, I strongly encourage you to start reviewing. I personally only know of one other bad thing in the API (the fact that the second argument to openCursor is a string rather than a dictionary), but since it's something that can be fixed in the next version I prefer to fix it there. There's also error handling which has been discussed on the mailing list but where the conclusions from that discussion needs to be added to the spec. / Jonas
Re: [IndexedDB] Numeric constants vs enumerated strings
On Tue, Feb 28, 2012 at 6:31 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 28 Feb 2012 17:56:05 +0100, Jonas Sicking jo...@sicking.cc wrote: Just to be clear. We've all been here long enough to know that Last Call is not what matters, what matters is when implementations ship and when enough content is authored that making incompatible changes will break too much content. This is an argument you yourself has made in other specifications and which I agree is reality we have to live with. I've mostly made that argument when defining legacy features I hope. Last I think I heard it was in relation to renaming CORS headers which also is in WD stage. I do think for new features we should have some explicit call for review when the initial 80% of the work is done. Sounds like a good idea. We should start doing that. What's the process for getting that adopted as an official W3C or WebApps policy? Also, I believe to date no implementation has shipped Indexed DB per specification (that is, without prefix) so that we have this argument at all given that everyone should agree that following Web IDL is important is somewhat surprising to me. We could certainly try to make this change when unprefixing, but at that point I think it'll create more confusion and messyness than the value it introduces. If you are worried IndexedDB hasn't received enough review, I strongly encourage you to start reviewing. I don't think I'm necessarily the right person, but I've pointed out that I think DOMStringList and numeric constants should go. I still don't have a good enough understanding of what DOMString[] means as far as being immutable goes. Possibly it's also something we can change in v2. / Jonas
FileSystem API: Adding file size field to Metadata?
Hi, While looking at the FileSystem API draft I noticed that we only expose 'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't have 'size' field unlike File object maybe it's reasonable to add 'size' field to Metadata? http://www.w3.org/TR/file-system-api/#the-metadata-interface Without adding this we can indirectly get the file size by creating 'File' object via FileEntry.file() method and accessing File.size, but when an app wants to display the modificationTime and file size at once (and it sounds very plausible use case) the app needs to call two different async methods-- which doesn't sound very nice. WDYT? Thanks, Kinuko
Re: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]
From: Jonas Sicking jo...@sicking.cc I think we've been feature complete for a while now. With one exception, which is that some error handling that we've discussed on the list needs to be edited into the spec. Apart from that we have a number of fairly minor uncontroversial fixes (details around generators, order in objectStore/index lists etc), and one more controversial fix (numeric vs. string constants). But these aren't new features by any means. I think the stuff that we have bugs on are mostly things that everyone agree that we can and should fix for v1 since they are mostly defining things that are currently undefined. There's one other bug that I wouldn't classify as minor, the one about getting an API for enumerating databases[1]. But other than that I agree. I'd love to see the currently open issues fixed though ;-) 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137 -- Odin
Re: April face-to-face meetings for HTML and WebApps
Dear All, At this time, the meeting will NOT happen on those dates since we didn't find a host for the meetings. I'm looking to see if we could do one in May/June (or July at most). As soon as we manage to secure a host for it, I'll propose new dates. Thank you to all who provided feedback, Philippe On Mon, 2012-02-06 at 17:58 -0500, Philippe Le Hegaret wrote: in order to facilitate the work of the WebApps and HTML Working Groups, I've been discussing with the Chairs the idea of having a face-to-face in the silicon valley in April. Due to various constraints (WWW2012 and Google I/O most notably), I ended up with the second week of April: - WebApps WG: April 10/11 (Tuesday/Wednesday) - HTML WG: April 12/13 (Thursday/Friday) - WebAppSec: April 11/12 (Wednesday/Thursday) Is anybody else aware of other potential conflicts? The WebKit contributor meeting dates are not set yet but may overlap with webapps for one day (April 10)... I asked the Chairs to ask for objections to those dates as well, Note that this meeting would be in addition to the TPAC 2012 in November (Lyon, France). Thank you, Philippe
Re: [IndexedDB] Numeric constants vs enumerated strings
On Tue, 28 Feb 2012 19:33:15 +0100, Jonas Sicking jo...@sicking.cc wrote: Last I think I heard it was in relation to renaming CORS headers which also is in WD stage. I have proposed renaming them if that is what you mean; people objected. We could certainly try to make this change when unprefixing, but at that point I think it'll create more confusion and messyness than the value it introduces. Why? The confusion is temporary, the API will be here for the lifetime of the platform. Your value trade-off seems questionable to me. I don't think I'm necessarily the right person, but I've pointed out that I think DOMStringList and numeric constants should go. I still don't have a good enough understanding of what DOMString[] means as far as being immutable goes. Possibly it's also something we can change in v2. By then people might rely on the contains() method or some such. There's a readonly DOMString[], Web IDL has details. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]
On Tue, Feb 28, 2012 at 10:51 AM, Odin Hørthe Omdal odi...@opera.comwrote: From: Jonas Sicking jo...@sicking.cc I think we've been feature complete for a while now. With one exception, which is that some error handling that we've discussed on the list needs to be edited into the spec. Apart from that we have a number of fairly minor uncontroversial fixes (details around generators, order in objectStore/index lists etc), and one more controversial fix (numeric vs. string constants). But these aren't new features by any means. I think the stuff that we have bugs on are mostly things that everyone agree that we can and should fix for v1 since they are mostly defining things that are currently undefined. There's one other bug that I wouldn't classify as minor, the one about getting an API for enumerating databases[1]. But other than that I agree. I'd love to see the currently open issues fixed though ;-) 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137 Are there implementations of the IDB*Sync APIs for Workers? Chromium has not yet implemented this rather large part of the spec, and last I checked (admittedly, some time ago) no-one else had either. This may have changed. If not, I'm worried there may be non-minor issues lurking there that will only be identified during implementation. (I'm a fan of the IETF's two genetically distinct implementations guidance for non-trivial specs.)
Re: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]
On Tue, Feb 28, 2012 at 11:13 AM, Joshua Bell jsb...@chromium.org wrote: Are there implementations of the IDB*Sync APIs for Workers? Gecko does not implement the IDBSync APIs, and I don't think that is likely to change in the next few months. - Kyle
Re: FileSystem API: Adding file size field to Metadata?
On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@chromium.org wrote: Hi, While looking at the FileSystem API draft I noticed that we only expose 'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't have 'size' field unlike File object maybe it's reasonable to add 'size' field to Metadata? http://www.w3.org/TR/file-system-api/#the-metadata-interface Without adding this we can indirectly get the file size by creating 'File' object via FileEntry.file() method and accessing File.size, but when an app wants to display the modificationTime and file size at once (and it sounds very plausible use case) the app needs to call two different async methods-- which doesn't sound very nice. WDYT? Thanks, Kinuko I think this is a nice improvement. File size is very obviously something one might expect to be included in meta data for a file :-) -Darin
Re: FileSystem API: Adding file size field to Metadata?
On Feb 28, 2012, at 1:52 PM, Darin Fisher da...@chromium.org wrote: On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@chromium.org wrote: Hi, While looking at the FileSystem API draft I noticed that we only expose 'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't have 'size' field unlike File object maybe it's reasonable to add 'size' field to Metadata? http://www.w3.org/TR/file-system-api/#the-metadata-interface Without adding this we can indirectly get the file size by creating 'File' object via FileEntry.file() method and accessing File.size, but when an app wants to display the modificationTime and file size at once (and it sounds very plausible use case) the app needs to call two different async methods-- which doesn't sound very nice. WDYT? Thanks, Kinuko I think this is a nice improvement. File size is very obviously something one might expect to be included in meta data for a file :-) Content type may be nice as well. Whatever the OS reports. -Charles
Re: [file-writer] WebIDL / References
On Sat, Feb 25, 2012 at 5:02 AM, Ms2ger ms2...@gmail.com wrote: Hi all, There are a number of bugs in the WebIDL blocks in http://dev.w3.org/2009/dap/file-system/file-writer.html. * The 'in' token has been removed; void append (in Blob data); should be void append (Blob data);. Fixed. * Event handlers should be [TreatNonCallableAsNull] Function? onfoo, not just Function. Fixed. * Interfaces should not have [NoInterfaceObject] without a good reason. Fixed. * FileException doesn't exist anymore; use DOMException. Still to come. Also, the References section is severely out of date. Fixed. HTH Ms2ger
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters sim...@opera.com wrote: I think WebSocket should do the same, for the same reason. Have you filed a bug? (No, not until this conversation moves along a bit further.) On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking jo...@sicking.cc wrote: I agree that it scrambles the data. But no more than the HTML parser error recovery does. And if an unexpected exception is thrown then the result is likely dataloss which is not obviously better than scrambling part of the data. I'd say it's weaker than scrambles, actually, at least with human-readable text. Replacing one character with U+FFFD usually results in an isolated glitch that a reader can recover from. (I do this regularly when reading the HTML spec, which uses characters not widely supported, in particular Steps in synchronous sections are marked with ?.) Also, even if you're attentive to handling these errors, most of the time you don't want to. In my experience, it's very uncommon to want to explicitly handle very rare errors like the user pasted in an unpaired surrogate. There's rarely anything useful you can do, except to walk through the string and change the unpaired surrogates to U+FFFD, so you can move on. I'd rather just get U+FFFD to begin with. -- Glenn Maynard
FileReader abort, again
I like the Event Invariants writeup at the end. It's only informative, but it is, indeed, informative. However, I'm not sure it quite matches the normative text in one respect. Where you say [8.5.6 step 4]: Terminate any steps while processing a read method. Does that also terminate the steps associated with an abort that terminated the read method? Basically I'm not sure what steps while processing a read method means. Otherwise, if you start a new read in onabort [8.5.6 step 5], you'll still deliver the loadend [8.5.6 step 6]. This contradicts 8.5.9.2.1 Once a loadstart has been fired, a corresponding loadend fires at completion of the read, EXCEPT if the read method has been cancelled using abort() and a new read method has been invoked. Eric [copying this into FileWriter]
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters sim...@opera.com wrote: I think WebSocket should do the same, for the same reason. Have you filed a bug? (No, not until this conversation moves along a bit further.) On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking jo...@sicking.cc wrote: I agree that it scrambles the data. But no more than the HTML parser error recovery does. And if an unexpected exception is thrown then the result is likely dataloss which is not obviously better than scrambling part of the data. I'd say it's weaker than scrambles, actually, at least with human-readable text. Replacing one character with U+FFFD usually results in an isolated glitch that a reader can recover from. (I do this regularly when reading the HTML spec, which uses characters not widely supported, in particular Steps in synchronous sections are marked with ?.) Also, even if you're attentive to handling these errors, most of the time you don't want to. In my experience, it's very uncommon to want to explicitly handle very rare errors like the user pasted in an unpaired surrogate. There's rarely anything useful you can do, except to walk through the string and change the unpaired surrogates to U+FFFD, so you can move on. I'd rather just get U+FFFD to begin with. OK, I've updated the Editor's Draft to reflect this. Essentially, I take Anne's advice about first converting the DOMString to a sequence of Unicode characters using the algorithm defined in WebIDL (namely this one: http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode). This actually seems to take care of unmatched surrogates from UTF-16 when you use a UTF-8 decoding on the Unicode characters following the algorithmic conversion, and so we may have what we need here. This is the 29th February Editor's Draft (ensure you shift-reload if necessary): http://dev.w3.org/2006/webapi/FileAPI/ I'd appreciate a review. If this passes muster, we may be one step further along the way to deprecating BlobBuilder, which only stipulated writing out as UTF-8 when the DOMString was appended to the Blob. -- A*
RE: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]
IE is not planning on implementing the IDBSync APIs for IE10 and we proposed to mark them “At Risk” on the current spec. Israel On Tuesday, February 28, 2012 11:17 AM, Kyle Huey wrote: On Tue, Feb 28, 2012 at 11:13 AM, Joshua Bell jsb...@chromium.orgmailto:jsb...@chromium.org wrote: Are there implementations of the IDB*Sync APIs for Workers? Gecko does not implement the IDBSync APIs, and I don't think that is likely to change in the next few months. - Kyle
Re: Colliding FileWriters
On Mon, Feb 27, 2012 at 6:40 PM, Jonas Sicking jo...@sicking.cc wrote: To do the locking without requiring calls to .close() or relying on GC we use a similar setup to IndexedDB transactions. I.e. you get an object which represents a locked file. As long as you use that lock to read from and write to the file the lock keeps being held. However as soon as you return to the event loop from the last progress notification from the last read/write operation, the lock is automatically released. This sounds a lot like microtasks, described here: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html. I don't know where it's described in IndexedDB, but it seems like this is a notion that keeps coming up again and again. It seems like this should be introduced as a consistent concept in the event model. Actually, it looks like this was just discussed on IRC: http://krijnhoetmer.nl/irc-logs/whatwg/20120228#l-39. I was a little confused at the above explanation. I think what you mean is that the lock is held so long as a FileRequest object is active (eg. has yet to dispatch a success or error event). More concretely, at the end of each microtask (if you want to use that terminology), all LockedFiles without any active FileRequests are released. That's sort of like the release when the LockedFile is GC'd approach, except it's deterministic and doesn't expose GC. (I think that's equivalent to what you said later, but I want to make sure I'm following correctly.) One downside of this is that it means that if you're doing a bunch of separate read/write operations in separate locks, each lock is held until we've had a chance to fire the final success event for the operation. So if you queue up a ton of small write operations you can end up mostly sitting waiting for the main thread to finish posting events. It'd only slow things down if you attach an expensive, long-running event handler to a load/loadend event, which is an inherently bad idea if you're doing lots of tiny operations. Is that actually a problem? (If those events were run from a queued task then it could be a problem, since it would have to wait for the event loop to get around to running those tasks, but they're fired directly from the algorithm itself.) By the way, readAsText and readAsArrayBuffer don't seem to fire load and loadend events at the end, like readAsDataURL does. It looks like an oversight--they're fired in the error path. -- Glenn Maynard
[Bug 16157] New: WebSocket shouldn't throw SyntaxError on unpaired surrogates
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157 Summary: WebSocket shouldn't throw SyntaxError on unpaired surrogates Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: gl...@zewt.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org If the method's second argument has any unpaired surrogates, then throw a SyntaxError exception and abort these steps. and If the data argument has any unpaired surrogates, then throw a SyntaxError exception. Don't throw exceptions on unpaired surrogates. Instead, use the WebIDL convert a DOMString to a sequence of Unicode characters [1] algorithm, which converts unpaired surrogates to U+FFFD, as well as defining the conversion itself. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1589.html [1] http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode -- Configure bugmail: https://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: [FileAPI, common] UTF-16 to UTF-8 conversion
On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.comwrote: or use another algorithm with an identical result, and be decoded as UTF-8. I think this can be removed. You can always replace algorithms with equivalent ones, in any part of an implementation. and be decoded as UTF-8. This should say encoded. Unicode codepoints are the raw data; UTF-8 is the encoding of that data. Should the actual UTF-8 encoding algorithm be specified by HTML? I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16157 for WebSocket. -- Glenn Maynard
