Re: Indexed DB + Promises

[Kyle Huey]

On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr.  wrote:
> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola  wrote:
>> I guess part of the question is, does this add enough value, or will authors 
>> still prefer wrapper libraries, which can afford to throw away backward 
>> compatibility in order to avoid these ergonomic problems? From that 
>> perspective, the addition of waitUntil or a similar primitive to allow 
>> better control over transaction lifecycle is crucial, since it will enable 
>> better wrapper libraries. But the .promise and .complete properties end up 
>> feeling like halfway measures, compared to the usability gains a wrapper can 
>> achieve. Maybe they are still worthwhile though, despite their flaws. You 
>> probably have a better sense of what authors have been asking for here than 
>> I do.
>
> Remember that the *entire point* of IDB was to provide a "low-level"
> set of functionality, and then to add a sugar layer on top once
> authors had explored the space a bit and shown what would be most
> useful.
>
> I'd prefer we kept with that approach, and defined a consistent,
> easy-to-use sugar layer that's just built with IDB primitives
> underneath, rather than trying to upgrade the IDB primitives into more
> usable forms that end up being inconsistent or difficult to use.
>
> ~TJ
>

At a bare minimum we need to actually specify how transaction
lifetimes interact with tasks, microtasks, etc.  Especially since the
behavior differs between Gecko and Blink (or did, the last time I
checked).

waitUntil() alone is a pretty large change to IDB semantics. Somebody
mentioned earlier that you can get this behavior today which is true,
but it requires you to continually issue "keep-alive" read requests to
the transaction, so it's fairly obvious you aren't using it as
intended.

- Kyle

Re: Exposing structured clone as an API?

[Kyle Huey]

On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 4/23/15 6:34 PM, Elliott Sprehn wrote:

 Have you benchmarked this? I think you're better off just writing your
 own clone library.


 That requires having a list of all objects browsers consider clonable and
 having ways of cloning them all, right?  Maintaining such a library is
 likely to be a somewhat demanding undertaking as new clonable objects are
 added...

 -Boris


Today it's not demanding, it's not even possible.  e.g. how do you
duplicate a FileList object?

- Kyle

Re: Blob URL Origin

[Kyle Huey]

On Mon, May 19, 2014 at 2:33 AM, Frederik Braun fbr...@mozilla.com wrote:
 On 15.05.2014 22:46, Glenn Maynard wrote:
 On Thu, May 15, 2014 at 12:07 PM, Jonas Sicking jo...@sicking.cc
 mailto:jo...@sicking.cc wrote:

 On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl
 mailto:ann...@annevk.nl wrote:
  I was thinking about the latter and that would not work if the URL was
  revoked. Unless we store origin at parse time.

 Good point. Without using the explicit syntax we couldn't return a
 consistent result for the origin.


 I'm not against the explicit model, but I think it would be very
 desirable if there was a way to get the origin out of the blob URL with
 some sort of API.
 It's not unlikely that developers will implement their own (flawed) URL
 parsing to determine the origin of a blob URL, if it's explicitly in the
 blob URL.

There's no way to extract the origin from the blob URL.  The URL is
just something of the form
blob:0ffc771c-486d-4cb0-8b7c-07b8dd9ab101.

- Kyle

Re: Blob URL Origin

[Kyle Huey]

It was pointed out to me that I should have read the rest of the thread ...

*looks sheepish*

- Kyle

On Mon, May 19, 2014 at 9:51 AM, Kyle Huey m...@kylehuey.com wrote:
 On Mon, May 19, 2014 at 2:33 AM, Frederik Braun fbr...@mozilla.com wrote:
 On 15.05.2014 22:46, Glenn Maynard wrote:
 On Thu, May 15, 2014 at 12:07 PM, Jonas Sicking jo...@sicking.cc
 mailto:jo...@sicking.cc wrote:

 On Thu, May 15, 2014 at 6:52 AM, Anne van Kesteren ann...@annevk.nl
 mailto:ann...@annevk.nl wrote:
  I was thinking about the latter and that would not work if the URL was
  revoked. Unless we store origin at parse time.

 Good point. Without using the explicit syntax we couldn't return a
 consistent result for the origin.


 I'm not against the explicit model, but I think it would be very
 desirable if there was a way to get the origin out of the blob URL with
 some sort of API.
 It's not unlikely that developers will implement their own (flawed) URL
 parsing to determine the origin of a blob URL, if it's explicitly in the
 blob URL.

 There's no way to extract the origin from the blob URL.  The URL is
 just something of the form
 blob:0ffc771c-486d-4cb0-8b7c-07b8dd9ab101.

 - Kyle

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Kyle Huey]

On Fri, Apr 18, 2014 at 4:08 AM, Dale Harvey d...@arandomurl.com wrote:
 Our current performance suite is @
 https://github.com/pouchdb/pouchdb/tree/master/tests/performance

 Its at a fairly abstract level above idb, and right now its not particularly
 clean, but it should be easy enough to get running, instructions @
 https://github.com/pouchdb/pouchdb/blob/master/CONTRIBUTING.md

 We have only just started on and the tests may not be great representations,
 but early signs are chrome and firefox are quite comparable with chrome
 being noticeably faster for keyrange queries, and safari being orders of
 magnitude faster

Thanks.  I assume you're using IndexedDB on Firefox and Chrome and
WebSQL on Safari?

I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=998324 for
investigating this on our end.

- Kyle

Re: Starting work on Indexed DB v2 spec - feedback wanted

[Kyle Huey]

On Thu, Apr 17, 2014 at 2:10 PM, Dale Harvey d...@arandomurl.com wrote:
 No features that slow it down, as with Tim I also implemented the same thing
 in node.js and see much better perfomance against straight leveldb, with
 websql still being ~5x faster than idb

Do you have benchmarks for this?  When we've profiled IndexedDB
performance for Gaia apps in the past the issue is invariably that the
main thread event loop is busy and IndexedDB's responses have to go to
the end of a long line.

- Kyle

Re: [FileAPI] Questions on using Blobs for img src and a href

[Kyle Huey]

Hi Brian,

Responses inline.

On Fri, Oct 4, 2013 at 6:35 AM, Brian Matthews (brmatthe) 
brmat...@cisco.com wrote:

  I've been doing some prototyping around displaying images with img
 src=blob:... and providing links to content using a href=blob:
 I've got it working, and it's all very cool, but there are a couple of
 things that seem like they could work better. They might be things that are
 too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to
 comment on, but I thought I'd ask here and see if there's something I'm
 missing, and make a suggestion.


I think that the first is an implementation bug.  The second is more
complicated.


  First is the status bar display for anchors while hovering over them. As
 expected, it's the blob URL. While this is completely correct and exactly
 what I'd expect, I'm not sure how useful it is. For an anchor with a
 normal URL, the user is told something about where the resource is (the
 domain name and path, http://example.com/order;), and what it is (the
 last element of the path, invoice.pdf). With a blob URL, they're told
 where it is (at least for those who know what a blob URL is, or accept that
 blob:... is something magic they don't need to know about :-) ), but
 nothing about what it is.


For instance, there's nothing in the spec requiring browsers to display
URIs on hover at all.  This is kind of a tricky UI problem (data URIs have
similar issues).  Browsers probably want to show that clicking the link
goes somewhere, but the URI doesn't provide any useful information to the
user.

Second, and related, is what happens when someone saves an image or target
 of a link. In both cases with normal URLs, there's a name component and
 the user agent can use that as the name of the resulting file, or suggest
 it if doing a Save As With blob URLs, there is no name, so the user
 agent has to make up a name. So with Firefox one gets fun names
 like index.gif (when saving an img), or bf_UK+0O.gif and y+f+wR9a.pdf
 (when saving the target of an anchor), and Chrome uses the opaqueString
 part of the URL, resulting in names
 like 49c122d8-0958-4dfd-ac9c-0a6245c5f91f..gif. None of those exactly brim
 with semantic content.


If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition: filename=$
file.name was specified in an HTTP request.  I don't know if browsers
support Content-Disposition without inline/attachment specified.  This is
the sort of thing that would be appropriate to put in the spec.

While I might be (probably am) missing something, I don't think there's any
 work around for either. Even the standard
 onmouseover=window.status='map.gif' for the first doesn't work in most
 (all?) browsers these days. Given that, my suggestion would be to promote
 the name attribute from the File interface to the Blob interface, and use
 it (if not null) when constructing blob URLs:
 blob:49c122d8-0958-4dfd-ac9c-0a6245c5f91f/map.gif. When using such a blob
 URL to locate the Blob in memory, the user agent would ignore everything
 after the first slash (just as it does with #, and presumably, although the
 standard doesn't, but probably should, state such, ?). When saving the
 contents of the Blob on the filesystem, the user agent would use the Blob's
 name as the file name, and when doing a Save As... type operation, would
 suggest the same as the file name. Or, as an alternative to promoting the
 name attribute, scripts could add the file names (as they can add fragment
 identifiers (and query strings?) today) to blob URLs and the user agent
 would take everything between the last unescaped / and first unescaped # or
 ? as the file name.


I don't think we want to introduce yet another way to parse URIs (which is
what treating '/' as special for blob would do).

Note that from the spec one would think I could do a new File(myBlob,
 myFilename), but both Firefox and Chrome throw exceptions when I do that
 (is that expected?), and if I use a real File (from a FileList), the name
 doesn't flow through to the blob URL and isn't used when saving.


I suspect this is just not implemented yet.

- Kyle

blob URIs and the query string

[Kyle Huey]

The File API specifies how to deal with fragment identifiers.  It should
also specify what to do with the query string.  Presumably it should be
ignored when looking up blob URIs.

- Kyle

Re: blob URIs and the query string

[Kyle Huey]

Well the query string is meant for the server, so what would you do with it?

- Kyle


On Wed, Oct 2, 2013 at 1:10 PM, pira...@gmail.com pira...@gmail.com wrote:

 Could it be procesed someway instead?
 El 02/10/2013 03:34, Kyle Huey m...@kylehuey.com escribió:

 The File API specifies how to deal with fragment identifiers.  It should
 also specify what to do with the query string.  Presumably it should be
 ignored when looking up blob URIs.

 - Kyle

Re: blob URIs and the query string

[Kyle Huey]

Oh, sure.  I'm not saying we should drop the query string entirely, I'm
saying that blob:foo and blob:foo?bar should both load the same thing.  If
someone does iframe src=blob:foo?bar and the script inside that blob
looks at bar and does processing on it that's fine.

- Kyle


On Wed, Oct 2, 2013 at 1:31 PM, pira...@gmail.com pira...@gmail.com wrote:

 Query can also be procesed by client-side javascript...
 El 02/10/2013 07:25, Kyle Huey m...@kylehuey.com escribió:

 Well the query string is meant for the server, so what would you do with
 it?

 - Kyle


 On Wed, Oct 2, 2013 at 1:10 PM, pira...@gmail.com pira...@gmail.comwrote:

 Could it be procesed someway instead?
 El 02/10/2013 03:34, Kyle Huey m...@kylehuey.com escribió:

 The File API specifies how to deal with fragment identifiers.  It should
 also specify what to do with the query string.  Presumably it should be
 ignored when looking up blob URIs.

 - Kyle

Re: [IndexedDB] Inform script of corruption recovery

[Kyle Huey]

On Thu, May 9, 2013 at 4:09 PM, David Grogan dgro...@chromium.org wrote:

 On Thu, May 9, 2013 at 4:01 PM, David Grogan dgro...@chromium.org wrote:

 jsbell pointed out an annoyance with this approach. If we delete the
 entire backing store while opening a database, we can alert the page that
 that particular database was lost via the mechanism discussed in this
 thread.


 To clarify, chromium stores all databases for an origin in a single
 leveldb instance, so this is a real possibility for us.


Yeah, I fear that giving anything remotely specific gets too far into
implementation-detail land.

- Kyle

Re: Web SQL and SQL

[Kyle Huey]

WebSQL is dead.  See
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0451.html.

- Kyle

On Tue, May 7, 2013 at 8:20 PM, Dai Rees dr...@microsoft.com wrote:

 While researching the feasibility of using Web SQL for an internal
 project, I was taken aback by the use of raw SQL strings - I thought as an
 industry we had moved past that horrid hack :)

 My understanding is that Web SQL presents a simplified means of storing
 and retrieving relational data in the client for offline storage, and it
 isn't as though they need OLAP cubes, so allowing freeform SQL seems a bit
 dangerous - and leaves the spectre of implementation incompatibilities
 (like present-day SQL) free to stalk again.

 The main thing that concerns me is the risk of SQL injection - many of us
 are veterans of VBScript and PHP code that is wide-open (e.g. SELECT *
 FROM accounts WHERE username = $_POST['user']) so I'm surprised the
 current specification gives us a simple hand-waving dismissal: Authors are
 strongly recommended to make use of the ? placeholder feature of the
 executeSql() method, and to never construct SQL statements on the fly..

 I'd like to propose that the executeSql method be completely removed and
 replaced with individual functions that can be used to work with relational
 data in a safe, efficient manner. Please excuse the bias visible from my
 email address domain, but I think our Linq library is a good approach to
 follow, for example:

 db.from( tableName ).where( c, function(value) { return value  5; }
 ).orderBy( c).select(a, b, d);

 is safer than letting developers, who span a huge gamut of competence,
 play with fire, for example:

 var c = prompt(which column?);
 tx.executeSql(SELECT a, b, d FROM tableName WHERE  + c +   5 ORDER BY
  + c);

 Joins and other complex queries can be done:

 db.from(tableFoo).join(tableBar, a, g).select(tableFoo.a,
 tableBar.g);

 Seeming as aggregate operations (e.g. SUM, AVG, etc) are known to the
 implementation they can also be exposed directly:

 db.from(tableFoo).where(c, function(value) { return value  5;
 }).sum();

 This approach can be extended to replace the other core SQL statements,
 e.g..:

 db.update(tableName).where( c, function(value) { return value == 5; }
 ).select(a, b, d).set( 5, 7, 13 );
 db.insert(tableName).select(a, b, d).set( 5, 7, 13 );
 db.delete(tableName).where( c, function(value) { return value  5; });

 This approach has the advantage of providing syntax checking when the
 script is interpreted by the browser (rather than waiting for the SQL
 string to be executed first, which might never happen), making it
 impossible to perform SQL-injection attacks. This proposed API requires no
 introduction of new ECMAScript language features either (though not to be
 confused with the Linq language extensions to C# and VB.NET). It also
 eliminates SQL's counter-intuitive syntax which puts the SELECT projection
 before the sources, predicates and  joins - something that led to no end of
 confusion when I was starting-off with SQL.

Re: InedxedDB events : misconception?

[Kyle Huey]

On Mon, Apr 22, 2013 at 1:50 PM, Joshua Bell jsb...@chromium.org wrote:

 FWIW, we had a Chrome IDB bug report where someone used the developer
 tools to set a script breakpoint between the open() call and the event
 handler assignments. The debugger spins the event loop, so the event was
 dispatched before the handlers were assigned. The answer was so don't do
 that, but it's a similar API/platform gotcha leading to developer
 confusion.


I would claim that's an implementation bug.

- Kyle

Re: Persistent Storage vs. Database

[Kyle Huey]

On Fri, Mar 8, 2013 at 11:02 AM, Andrew Fedoniouk n...@terrainformatica.com
 wrote:

 On Thu, Mar 7, 2013 at 10:36 PM, Kyle Huey m...@kylehuey.com wrote:
  On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk
  n...@terrainformatica.com wrote:
 
  At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
 
 
  Easier doesn't necessarily mean better.  LocalStorage is certainly
 easier to
  use than any async storage system ;-)
 

 At least my implementation does not use any events. Proposed
 system of events in IndexedDB is the antipattern indeed. Exactly for
 the same reasons as finalizer *events* you've mentioned above - there
 is no guarantee that all events will be delivered to the code awaiting
 and relaying on them.


That's not true at all.  If you don't understand the difference between
finalizers and events you're not going to be able to make a very informed
criticism of IndexedDB.

- Kyle

Re: Persistent Storage vs. Database

[Kyle Huey]

On Thu, Mar 7, 2013 at 10:20 PM, Andrew Fedoniouk n...@terrainformatica.com
 wrote:

 Physical commit (write) of objects to storage happens on either
 a) GC cycle or b) on explicit storage.commit() call or on c) VM shutdown.


Persisting data off a GC cycle (via finalizers or something else) is a
pretty well known antipattern.[0]

At least it is easier than http://www.w3.org/TR/IndexedDB/ :)


Easier doesn't necessarily mean better.  LocalStorage is certainly easier
to use than any async storage system ;-)

 - Kyle

[0] e.g.
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx

Re: IndexedDB: IDBOpenDBRequest sequencing

[Kyle Huey]

On Thu, Jan 10, 2013 at 1:30 PM, Joshua Bell jsb...@chromium.org wrote:

 Pinging the group again on this topic.

 (I sent this out just before the holidays so I wasn't surprised to see
 this overlooked.)


Jonas filed https://bugzilla.mozilla.org/show_bug.cgi?id=823371 so he at
least considers this a Gecko bug.

You are correct in that Gecko currently only allows one IDBOpenDBRequest to
be running against a database at a time.

- Kyle

Re: [IndexedDB] Inform script of corruption recovery

[Kyle Huey]

On Tue, Feb 12, 2013 at 1:49 PM, David Grogan dgro...@chromium.org wrote:

 I think the answer to that question impacts how we design this.


 I'm assuming you mean because a surgical recovery could leave the version
 intact and make a new property on the upgradeneeded event inaccessible? In
 that case we could also put the property on the success event that comes in
 response to open().


Well I was thinking more like being able to recover one object store and
not others.  But this does raise an interesting question.  If we can
restore to the same db version, but not identical contents, how would we
indicate that to the page?  Is there anything more useful we can provide
than someDataWasLost=true?  Doesn't seem like it.

- Kyle

(Sorry for the delay responding, been on vacation).

Re: [IndexedDB] Inform script of corruption recovery

[Kyle Huey]

On Mon, Feb 11, 2013 at 10:40 PM, David Grogan dgro...@chromium.org wrote:

 When chrome opens an IDB database, it attempts to detect corruption. If
 the database appears to have been corrupted, either via software bug or
 hardware fault, chrome performs recovery. As currently implemented (we
 may try to do something more surgical in the future), recovery
 means removing all the origin's databases from disk and creating a new
 empty database. It would be useful to alert script that some data has been
 lost in this situation. The web app could then alert the user or take other
 appropriate action. This is important in offline editing scenarios, where
 this represents true user data loss rather than just a flush of a data
 cache.


Do you expect to ever be able to implement something more granular than a
per-database recover or discard?  I would imagine that's as surgical as it
is going to get.  I think the answer to that question impacts how we design
this.

Some options we've discussed:
 * Do nothing; web apps could mirror the latest version in localStorage and
 look for discrepancies.
 Pro: No changes to the IDB API.
 Con: Lame to make web developers rely on another storage mechanism to
 handle IDB corruption.


This is a) terrible and b) ineffective.  Why wouldn't LS be subject to
similar corruption problems?  In Firefox we currently use SQLite as the
ultimate backing store for both LS and IDB, but even if we were using
different backing stores, I wouldn't see any reason to choose the *less*
reliable one for IDB.  That said, we shouldn't be promoting LS for
anything, certainly not for limitations of IDB.


 * Report to the user via pop-up, not script
 Pro: No changes to the IDB API.
  Con: Opaque to the web app. Not actionable to the user. Prevents any
 app-level appropriate response.


The user can't do anything useful with this information.


 * Property on the upgradeneeded event. If a corrupt database was blown
 away, oldVersion would be 0 but a reason property could indicate
 corruption; and similarly,
 * Property on IDBDatabase indicating if recovery had to be performed
 during opening (e.g. dataLoss with values none, total, and
 potentially partial)
 Pro: Surfacing error to the app allows for app-specific action or options
 presented to the user.
 Con: Not very elegant, the extra property is wart-like.


This is my preferred alternative.  Setting the property on upgradeneeded
makes the most sense, IMO, because recovering from corruption is a
transitory state, not one associated with the IDBDatabase indefinitely.


 * Change open flow - in case corruption is detected, open fails with
 diagnostic error, but can be retried by script e.g. indexedDB.open(name,
 version, { recover: true }) - i.e. what chrome does automatically/silently
 for scripts today
 Pro: Gives app control over how to handle corruption.
 Con: Complex. Until implementations perform a nuanced recovery, the extra
 control isn't terribly useful.


The opening flow is complex enough already.  I would hesitate to make it
more complicated.


 We've been leaning toward the extra property on IDBDatabase or the
 upgradeneeded event but are interested in hearing opinions.


Of the identified options an extra property on upgradeneeded is by far my
preferred choice.

- Kyle

Re: Reading image bytes to a PNG in a typed array

[Kyle Huey]

On Mon, Jan 14, 2013 at 7:04 AM, Florian Bösch pya...@gmail.com wrote:

 On Mon, Jan 14, 2013 at 4:00 PM, Glenn Maynard gl...@zewt.org wrote:

 You want toBlob, not toDataURL.

 So how would I stick a blob into an arraybuffer?


I don't think there's any reason we can't have toArrayBuffer as well.  The
hard part from an implementation perspective is asynchronously encoding the
image, not what we stick it in.

- Kyle

Re: [IndexedDB] How to recover data from IndexedDB if the origin domain don't exist anymore?

[Kyle Huey]

On Tue, Jan 15, 2013 at 3:57 PM, pira...@gmail.com pira...@gmail.comwrote:

 Ideas? Doubts? Comments? :-)


The use case here is not compelling enough for this amount of complexity.
IndexedDB is not guaranteed to be persistent so you can't really have a
server-less webapp if you want reliability.  Once you have server-side
state there's no point in jumping through all these hoops if you switch
domains, just repopulate the DB from the server.

- Kyle

Re: Reading image bytes to a PNG in a typed array

[Kyle Huey]

On Wed, Jan 16, 2013 at 7:50 AM, Glenn Maynard gl...@zewt.org wrote:

 On Wed, Jan 16, 2013 at 9:40 AM, Florian Bösch pya...@gmail.com wrote:

 Perhaps we should think of a better scheme to export data than toFoo().
 Maybe toData('url'), toData('arraybuffer') toData('blob') or perhaps
 toData(URL), toData(ArrayBuffer) or toData(Blob). I tend to think that if
 you're starting to write toA, toB, toC, toX methods on an object, you've
 not thought this really trough what's a parameter, and what's a method.


 We should be avoiding the need to return data in a bunch of different
 interfaces in the first place.  If the data is large, or takes a long or
 nondeterministic amount of time to create (eg. something that would be
 async in the UI thread), return a Blob; otherwise return an ArrayBuffer.
  The user can convert from there as needed.


Well, the problem is that we fundamentally screwed up when we specced
Blob.  It has a synchronous size getter which negates many of the
advantages of FileReader extracing data asynchronously.  For something like
image encoding (that involves compression), where you have to perform the
operation to know the size, Blob and ArrayBuffer are effectively
interchangeable from the implementation perspective, since both require you
to perform the operation up front.

- Kyle

Re: CfC: publish WD of XHR; deadline November 29

[Kyle Huey]

On Sun, Nov 25, 2012 at 10:34 AM, David Bruant bruan...@gmail.com wrote:

 Le 22/11/2012 18:16, Ms2ger a écrit :

  On 11/22/2012 02:01 PM, Arthur Barstow wrote:

 TheXHR Editors  would  like to publish a new WD of XHR and this is a
 Call for  Consensus to do so using the following ED (not yet using the
 WD template) as the basis
 http://dvcs.w3.org/hg/xhr/**raw-file/tip/Overview.htmlhttp://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
 .

 Agreement to this proposal: a) indicates support for publishing a new
 WD; and b) does not necessarily indicate support of the contents of the
 WD.

 If you have any comments or concerns about this proposal, please reply
 to this e-mail by December 29 at the latest.

 Positive response to this CfC is preferred and encouraged and silence
 will be assumed to mean agreement with the proposal.


 I object unless the draft contains a clear pointer to the canonical spec
 on whatwg.org.

 I'm unfamiliar with the W3C process, so sorry if my question is stupid,
 but why would it be necessary? (I assume you're talking about
 http://xhr.spec.whatwg.org/)

 Quoting http://xhr.spec.whatwg.org/
 Editor:
 Anne van Kesteren ann...@annevk.nl

 CC0 To the extent possible under law, the editor has waived all copyright
 and related or neighboring rights to this work. In addition, as of 22
 November 2012, the editor has made this specification available under the
 Open Web Foundation Agreement Version 1.0, which is available at
 http://www.openwebfoundation.**org/legal/the-owf-1-0-**agreements/owfa-1-0http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.
 

 Quoting http://www.openwebfoundation.**org/legal/the-owf-1-0-**
 agreements/owfa-1-0http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0(emphasis
  is mine)
 2.1.   Copyright Grant.  I grant to you a perpetual (for the duration of
 the applicable copyright), worldwide, non-exclusive, no-charge,
 royalty-free, copyright license, *without any obligation for accounting to
 me*, to reproduce, prepare derivative works of, publicly display, publicly
 perform, sublicense, distribute, and implement the Specification to the
 full extent of my copyright interest in the Specification. 

 This wording makes pretty clear that pointing to the whatwg spec isn't
 required or necessary or anything.


 It would be pretty hypocritical to put some work under CC0/public
 domain/OWFAV1.0 and expect or even demand to be credited. Some licences
 (CC-BY as an example) require crediting the original author. I assume a
 purposeful choice has been made by Anne and the WHATWG to put the work
 under a licence that doesn't have such a requirement.
 Choosing a licence applied to some work shows an intention of how one
 expects the work to be reused. The intention here is pretty clear and says
 I don't care of being credited.
 Choosing a licence is a serious choice with serious implications.

 If the WHATWG expects credit, maybe it should consider re-licence its work
 (which would be easy given the current licence ;-) ) to a licence
 expressing more clearly this intent instead of expecting others to guess
 the intent and throwing accusations of plagiarism.

 David


Have you read Adam Barth's contributions to this discussion?  He has
summarized the point well, I think.  There is a difference between what the
license legally obligates one to do and what professionals working in good
faith towards similar goals do.

- Kyle

Re: [IndexedDB] Can IDBTransaction.oncomplete callback be used as active state?

[Kyle Huey]

On Sun, Nov 18, 2012 at 7:29 AM, Kyaw Tun kyaw...@yathit.com wrote:

 Transaction is active as long as I send request from the IDBRequest
 callback. Is there any other way to prevent committing?


No.  If at any point your JavaScript finishes executing there are no
running or pending requests the transaction becomes inactive.


 If there any way to detect transaction active flag?


Not directly.  Attempting to place a new request will fail with a
TransactionInactiveError though.


 I expect IDBTransaction.oncomplete callback can be used to flag inactive
 state, but it is not according to my few test. Transaction is already
 inactive and cannot be use even before receiving oncomplete callback.


oncomplete is called after the transaction is committed.  The transition
from active to inactive is what starts committing the transaction, so
oncomplete is far too late to determine that.

- Kyle

Re: [IndexedDB] coupled transactions

[Kyle Huey]

On Sun, Nov 18, 2012 at 7:54 AM, Kyaw Tun kyaw...@yathit.com wrote:

 Coupled transactions exists when two or more transactions should be
 committed together but transactions are in different scopes or mode.
 Currently I find this problem challenging to solve with IndexedDB API.

 This can be solved by merging transactions into single transaction,
 but it will be sub-optimal and require sharing transaction objects.

 The use case appear when we want to use producer-consumer pattern as
 follow:

 In producer object, a read transaction is created and index cursors
 are scanning to find a matching keys. Whenever it find a match key, it
 send to consumer object.

 Consumer object, a read or write transaction is created when it first
 received a key. The cursor value is use to render UI or update it to
 the database. In general, we are expecting to receive ordered sequence
 of keys. For optimal purpose, the transaction should be keep active.

 Concrete example:

 Consumer side
 --

 var out = new ydn.db.Streamer(db, 'animals', 'id');
   out.setSink(function(key, value) {
 console.log(['receiving', key, value]); // should be ['cow', 'cow']
   });


 Producer side
 
 var q1 = ydn.db.Iterator.where('animals', 'color', '=', 'spots');
 var q2 = ydn.db.Iterator.where('animals', 'horn', '=', 1);
 var q3 = ydn.db.Iterator.where('animals', 'legs', '=', 4);
 var solver = new ydn.db.algo.NestedLoop(out);
 var req = db.scan([q1, q2, q3], solver);


 data
 --
 animals = [
 {id: 'rat', color: 'brown', horn: 0, legs: 4},
 {id: 'cow', color: 'spots', horn: 1, legs: 4},
 {id: 'galon', color: 'gold', horn: 1, legs: 2},
 {id: 'snake', color: 'spots', horn: 0, legs: 0},
 {id: 'chicken', color: 'red', horn: 0, legs: 2}
   ];






 Ref: test_31_scan_mutli_query_match in

 https://bitbucket.org/ytkyaw/ydn-db/raw/0e1e33582cfed54c9baf1d5bb134cae58bac45c8/test/iteration_test.js


I don't understand why the two transactions need to be coupled.  The
producer object has a read only transaction, so it won't commit any
changes.  The consumer object has a read write transaction.  If it's
modifying the same object stores the producer object is reading from, that
transaction will block until the producer's transaction is inactive, so the
producer will receive a coherent snapshot of data.

- Kyle

Re: Two years on and still no sensible web storage solutions exist

[Kyle Huey]

On Mon, Nov 12, 2012 at 4:30 AM, Florian Bösch pya...@gmail.com wrote:

 On Mon, Nov 12, 2012 at 1:12 PM, Charles McCathie Nevile 
 cha...@yandex-team.ru wrote:

 The Webapps group will continue to try and reach industry agreement on
 ways to handle data storage for offline applications. Help is appreciated.
 Trying to help is generally appreciated too.

 A slight tangent, but coming from WebGL where we're dealing with a lot of
 binary data, the inability of WebSQL and IndexedDB to deal with Array
 Buffers is quite an obstacle.


Er, IndexedDB should handle ArrayBuffers just fine.  If you're seeing
problems with that that's an implementation bug, not a case that the spec
failed to handle.

- Kyle

Re: Two years on and still no sensible web storage solutions exist

[Kyle Huey]

On Mon, Nov 12, 2012 at 9:52 AM, Joshua Bell jsb...@google.com wrote:

 Per the spec, anything the structured cloning algorithm [1] handles can be
 used as record values in IndexedDB. ArrayBuffers are not on that list, but
 Chrome does support them in IndexedDB.


The TypedArray spec specifies how to structured clone ArrayBuffers.

http://www.khronos.org/registry/typedarray/specs/latest/#9.1

- Kyle

[IndexedDB] Problems unprefixing IndexedDB

[Kyle Huey]

Hello all,

Jonas mentioned earlier on this list that we unprefixed IndexedDB in
Firefox nightlies some time ago.  We ran into a bit of a problem.[0]  Most
of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell
authors to deal with prefixing with:

var indexedDB = window.indexedDB || window.webkitIndexedDB ||
window.mozIndexedDB || window.msIndexedDB || ...

This code has a bug when executed at global scope.  Because the properties
are on the prototype chain of the global object, 'var indexedDB' creates a
new property on the global.  Then window.indexedDB finds the new property
(which has the value undefined) instead of the IDBFactory on the prototype
chain.  The result is that all of the pages that do this no longer work
after we unprefix IndexedDB.

Mozilla is the only vendor affected by this at the moment.  In our testing
on IE 10.0.8400.0, both a prefixed and unprefixed version of IndexedDB are
available, so the code above shadows the unprefixed version with the
prefixed version (which has no real effect).  In Chrome, attributes are on
the object itself instead of the prototype, so 'var indexedDB' at global
scope is a no-op.

Our options, as we see them now, are:
1. Make no code changes, and evangelize.
2. Move indexedDB to the global object itself (copy Chrome).
3. Put the prefixed version back temporarily (copy IE).

We'd prefer option 1 of course, if we can make that work.  Any thoughts are
welcome.  We'd especially like to know if IE has plans to drop the prefixed
version, and if Chrome is planning to move attributes to the prototype
anytime soon.

Thoughts?

- Kyle

PS. We're also going to run into this in the future with any other prefixed
DOM APIs we add to the global, probably even if we don't tell people to do
it wrong in our tutorials.  This behavior is a pretty massive footgun.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=770844
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=770844#c5

Re: WebIDL overload resolution, arrays and Nullable

[Kyle Huey]

On Fri, Jun 29, 2012 at 9:25 AM, Joshua Bell jsb...@chromium.org wrote:

 Over in WebKit-land there's some disagreement about WebIDL method overload
 resolution, specifically around passing null, arrays (T[]) and the concept
 of Nullable.

 Here's an example where we're just not sure what the WebIDL spec dictates:

 void f(float[] x); // overload A
 void f(DOMString x); // overload B

 WebIDL itself, of course, doesn't dictate how matching and dispatching
 should be implemented; it instead defines whether types are
 distinguishable. The implication is that an IDL that defines methods with
 signatures that are not distinguishable is invalid, so it's a non-issue in
 terms of the spec. So rephrasing the question: are the above types
 distinguishable? And if so, which would be expected to handle the call:

 f(null);

 Several interpretations and hence outcomes occur to us, hopefully
 presented without indicating my particular bias:

 (1) T[] is inherently Nullable (i.e. T[] === T[]?), DOMString is not,
 overload A would be invoked with a null argument and the implementation is
 expected to handle this case
 (2) T[] accepts null but the IDL type to ECMAScript conversion rules
 produce an empty array; overload A is invoked with an empty float array
 (3) T[] does not match null, but as null is an ECMAScript primitive value
 it is run through ToString() and hence overload B is invoked with DOMString
 null
 (4) Either T[] or DOMString could match null, so types of the arguments
 are not distinguishable and hence the above is invalid WebIDL
 (5) Neither T[] nor DOMString is inherently Nullable, so a TypeError is
 thrown

 Anyone? (Cameron?)


#5.  Neither T[] nor DOMString admits null as a value.

Note also that null is not a value of type DOMString. To allow null, a
nullable DOMString, written as DOMString? in IDL, needs to be used. 

http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString

The T[] type is a parameterized type. The values of this type are non-null
references to arrays of values of type T.

http://dev.w3.org/2006/webapi/WebIDL/#idl-array

- Kyle

Re: WebIDL overload resolution, arrays and Nullable

[Kyle Huey]

On Fri, Jun 29, 2012 at 9:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 6/29/12 12:37 PM, Kyle Huey wrote:

 #5.  Neither T[] nor DOMString admits null as a value.


 DOMString does not admit null as an IDL value.

 Which means that ES null is stringified when converting to DOMString.

 -Boris

 Ah yes, I forgot about that.

Thanks for the correction.

- Kyle

[IndexedDB] Origins and document.domain

[Kyle Huey]

By my reading, the spec does not clearly specify what the 'origin' should
be.  IDBFactory.open/deleteDatabase say Let origin be the origin of the
IDBEnvironment used to access this IDBFactory.  The IDL states Window
implements IDBEnvironment;  The HTML5 spec, as far as I can tell, does not
define the concept of an origin for a window, but only for a document.

There is another related question here: how should IndexedDB behave in the
presence of modifications to document.domain?

- Kyle

[IndexedDB] Extracting keys and null/undefined

[Kyle Huey]

Consider an autoincrementing IDBObjectStore with keyPath foo.bar.

Which of the following (if any) should succeed?

1. objectStore.put({foo: null});
2. objectStore.put({foo: undefined});
3. objectStore.put({foo: {bar: null}});
4. objectStore.put({foo: {bar: undefined}});

By my reading of the spec, currently #1 and #2 succeed, and #3 and #4 do
not.

First, we look at the foo property on the object.  All 4 objects have a foo
property.  We take the value of the foo property and consider that further.
Then we look for a bar property.  Because 'null' and 'undefined' do not
have that property, we return from step 5 of the steps for extracting a
key from a value using a key path with no value for #1 and #2.  For #3 and
#4, we return the value of the bar property, null or undefined,
respectively.
IDBObjectStore.put throws if, among other conditions, the object store
uses in-line keys and the result of evaluating the object store's key path
yields a value and that value is not a valid key.  Since null and
undefined are not valid keys, #3 and #4 are rejected, while #1 and #2 go on
to receive autogenerated keys.

IMO, this is not intuitive behavior.

- Kyle

[IndexedDB] Exception inconsistency

[Kyle Huey]

If a keypath passed to createObjectStore fails certain constraints (not
passing arrays or empty strings to autoIncrement) the spec says to throw an
InvalidAccessError.

If a keypath passed to createIndex fails constraints (an array keypath
passed to a multientry index) the spec says to throw a NotSupportedError.

Why are these not consistent?

- Kyle

[IndexedDB] WebIDL-related spec nits

[Kyle Huey]

(Note, I did not include the various things relating to keyPath that I
mentioned last week, because I do not consider those to be trivial changes).

Globally, the spec is inconsistent about whether the prose is in the same
order as the IDL, or whether the prose is in alphabetical order.  I would
prefer the former, but consistency of some sort is desirable.

3.1.9

The return type of the static functions on IDBKeyRange is not 'static
IDBKeyRange', it is just 'IDBKeyRange'.

3.2.1

The correct type name is object, not Object (note the capitalization).

IDBRequest.readyState should be an enum type, not a DOMString.

3.2.2

IDBVersionChangeEvent should probably reference whatever spec defines how
constructors work for DOM events.

3.2.4

IDBDatabase.transaction's mode argument should be an enum type, with a
default value specified in IDL instead of in prose.

3.2.5

Is it intentional that IDBObjectStore.indexNames does not return the same
DOMStringList every time, unlike IDBDatabase.objectStoreNames (yes, I
realize that the circumstances under which the former can change are much
broader).

IDBObjectStore.openCursor's direction argument should be an enum type, with
a default value specified in IDL (right now it is unspecified).

3.2.6

IDBIndex.openCursor and IDBIndex.openKeyCursor's direction argument should
be an enum type, with a default value specified in IDL.

3.2.7

Object should be object.

3.2.8

IDBTransaction's mode attribute should be an enum type.

Also, it would be nice if we could tighten up keys from 'any' to a union.

- Kyle

Re: [IndexedDB] Key paths need to be specified better

[Kyle Huey]

On Fri, Jun 8, 2012 at 10:42 AM, Odin Hørthe Omdal odi...@opera.com wrote:

 Kyle Huey m...@kylehuey.com skreiv Fri, 08 Jun 2012 19:22:54 +0200


  In particular the spec states that key paths are DOMStrings, and then
 goes on to state how Array key paths are handled.  Whatever changes are
 made need to preserve the note about key paths not nesting just after 4.7.1.


 Definately seconded. We've had some misunderstandings because of this. You
 can give an array of keyPaths both consumers, but IDBObjectStoreParameters
 is totally lying straight to our face by saying DOMString?.
 IDBObjectStore.createIndex IDL is any keyPath, which is correct. It may
 even be clearer to write (DOMString? keyPath or DOMString[] keyPath) or do
 an overload. You'd have to ask someone who knows WebIDL better :-)


I believe the correct type is (DOMString or DOMString[])?.  That is, a
nullable union of DOMString or an array of DOMStrings.

- Kyle

[IndexedDB] Key paths need to be specified better

[Kyle Huey]

In particular the spec states that key paths are DOMStrings, and then goes
on to state how Array key paths are handled.  Whatever changes are made
need to preserve the note about key paths not nesting just after 4.7.1.

- Kyle

Re: [IndexedDB] Plans to get to feature complete [Was: Numeric constants vs enumerated strings ]

[Kyle Huey]

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: data and blob URLs in HTTP context

[Kyle Huey]

On Wed, Feb 15, 2012 at 4:45 AM, Julian Reschke julian.resc...@gmx.dewrote:

 On 2012-02-15 13:13, Julian Reschke wrote:

 On 2012-02-15 11:04, Anne van Kesteren wrote:

 On Sun, 05 Feb 2012 17:30:09 +0100, Julian Reschke
 julian.resc...@gmx.de wrote:

 On 2012-02-05 15:56, Anne van Kesteren wrote:

 Currently Opera and Firefox seem to support data URLs within the
 context
 of XMLHttpRequest. Status is 0, status text is the empty string, there
 are no response headers, and response-related attributes work as
 expected.
 ...


 No Content-Type response header?


 As far as I can tell, no.


 Well, data URIs come with a content type, so when XHR supports them,
 this header field should be made available...

 Best regards, Julian


 Can't get it to work in Firefox 10 (Error: uncaught exception:
 [Exception... Access to restricted URI denied  code: 1012 nsresult:
 0x805303f4 (NS_ERROR_DOM_BAD_URI)  location: http://greenbytes.de/tech/
 **webdav/data.html http://greenbytes.de/tech/webdav/data.html Line:
 8]).


XHR to data URIs is first supported in Gecko 12.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=702820.

- Kyle

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

On Thu, Feb 2, 2012 at 4:48 PM, Charles Pritchard ch...@jumis.com wrote:

 Blob.prototype.toString=function(){ return URL.createObjectURL(this);
 };


We *really* don't want to make a function that gets automatically called
leak memory like this.

- Kyle

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com

 img.src = blob;

 tells nothing about possible access to underlying data using URL identifier


And I think that if we're concerned about the blob being leaked for the
lifetime of the document (because the URL was never revoked) we should
abandon the blob URL approach entirely and pursue something else (such as
img.src = blob).

Adding manual memory management to the web platform is a step backwards,
IMO.

- Kyle

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com

 so just a line
 URL.createObjectUrl(blob)
 creates a memory leak? Heh?

 Which brink me to my previous question, what happened to Blob.URL? Just
 brink it back and this whole conversation can go away...


The only way blob.URL differs from URL.createObjectUrl is in syntax.  The
semantics are the same ... and the leak still exists.

- Kyle

Re: Image.toBlob()

[Kyle Huey]

2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com

 Hello,
 would it be possible to have Image.toBlob() function? We are introducing
 Canvas.toBlob(), image (and maybe video, audio) would be nice addition


 Brona


Proposing a more detailed spec would be a good place to start.  Some
example questions:

1. What does img.toBlob() do if the image failed to load?
2. Should img.toBlob() respect CORS?
3. Does img.toBlob() take a content type argument like the others?  If
so, what does img src=foo.jpg.toBlob(image/png) do?
4. Is img.toBlob() asynchronous like canvas.toBlob()?

I think the idea of implementing img.toBlob() is fine, but we need to
spec out the behavior first.

- Kyle

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

Why though?  What stops UAs from accepting the relevant objects for .src
properties?

- Kyle

On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson i...@hixie.ch wrote:

 On Sat, 28 Jan 2012, Kyle Huey wrote:
  On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org
 wrote:
  
   I'm not sure what a concrete proposal would look like.  Maybe
   Element.URL.createObjectURL or just Element.createObjectURL?
 
  Wouldn't returning an object (which can be GCd) be a better solution?

 The whole point of the API is that we have an object but need a string (a
 URL).

 --
 Ian Hickson   U+1047E)\._.,--,'``.fL
 http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org wrote:

 I'm not sure what a concrete proposal would look like.  Maybe
 Element.URL.createObjectURL or just Element.createObjectURL?


Wouldn't returning an object (which can be GCd) be a better solution?

- Kyle

Re: File modification

[Kyle Huey]

On Tue, Jan 10, 2012 at 10:57 PM, Charles Pritchard ch...@jumis.com wrote:

 Far as I can tell, File is live, and it's supposed to be live from input
 type=file.


 FWIW, I (and I believe others at Mozilla) consider the fact that File
objects are live in Gecko a bug.  Fixing this is kind of complicated in
our implementation though, and I've had other things to work on, so it's
still there.

- Kyle

Re: file sharing services

[Kyle Huey]

On Thu, Dec 1, 2011 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 It's possible that someone from this mailing list could contact those
 services.  It's more likely to happen, though, if you do it yourself.


I would expect that contacts from their paying customers would be more
effective than contacts from people on this list anyways.

- Kyle

Re: Is BlobBuilder needed?

[Kyle Huey]

On Tue, Nov 15, 2011 at 10:55 AM, Glenn Maynard gl...@zewt.org wrote:

 On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking jo...@sicking.cc wrote:

 It was pointed out to me on twitter that BlobBuilder can be replaced
 with simply making Blob constructable. I.e. the following code:


 I noticed this at
 https://developer.mozilla.org/en/Firefox_8_for_developers:

 BlobBuilder now has a getFile() method that returns the content of the
 blob as a file.

 This suggests a File constructor as well, eg. b = new File([foo, bar], {
 name: file.jpg });.

 (Of course, the only difference is that the created object has the File
 interface, with an attached filename.  It would make no difference to how
 the data is stored, which isn't actually tied to the interface.)


I think we decided that we're going to remove getFile.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later.

- Kyle

Re: Indexed database API autoIncrement

[Kyle Huey]

On Sun, Oct 23, 2011 at 7:20 AM, Futomi Hatano i...@html5.jp wrote:

 Hello everyone,

 I'm not a W3C member, can I send a mail to the list?


Yes, this mailing list is open to anyone.

I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
 I found a different behavior between the two.
 I set autoIncrement to true when I created a Object Store as below.

 var store = db.createObjectStore(store_name, { keyPath: 'id',
 autoIncrement: true });

 Then, I added some records.

 IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set
 it to 1.
 Which is correct?


This is a good question.  I don't believe that the spec specifies this.

- Kyle

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

[Kyle Huey]

To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.  (
https://bugzilla.mozilla.org/show_bug.cgi?id=657964)

We have not changed the timing of the events, which are still dispatched
synchronously.

- Kyle

On Tue, May 17, 2011 at 3:01 PM, Kyle Huey m...@kylehuey.com wrote:

 There is actually another difference, the writing API sets the error,
 readystate value, and dispatches events off of a queued task, while the
 reading API does that synchronously.

 I'm inclined to think the synchronous version is the way to go here, since
 then the FileReader or FileWriter is totally ready for another use once the
 abort method returns.  This is less interesting for FileSaver since that can
 only do one thing.

 - Kyle

 On Tue, May 17, 2011 at 2:35 PM, Kyle Huey m...@kylehuey.com wrote:

 The abort behaviors of FileReader and File[Saver|Writer] differ.  The
 writing objects throw if the abort method is called when a write is not
 currently under way, while the reading object does not throw.

 The behaviors should be consistent.  I don't particularly care either way,
 but I believe Jonas would like to change FileReader to match
 File[Saver|Writer].

 - Kyle

[FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

[Kyle Huey]

The abort behaviors of FileReader and File[Saver|Writer] differ.  The
writing objects throw if the abort method is called when a write is not
currently under way, while the reading object does not throw.

The behaviors should be consistent.  I don't particularly care either way,
but I believe Jonas would like to change FileReader to match
File[Saver|Writer].

- Kyle

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

[Kyle Huey]

There is actually another difference, the writing API sets the error,
readystate value, and dispatches events off of a queued task, while the
reading API does that synchronously.

I'm inclined to think the synchronous version is the way to go here, since
then the FileReader or FileWriter is totally ready for another use once the
abort method returns.  This is less interesting for FileSaver since that can
only do one thing.

- Kyle

On Tue, May 17, 2011 at 2:35 PM, Kyle Huey m...@kylehuey.com wrote:

 The abort behaviors of FileReader and File[Saver|Writer] differ.  The
 writing objects throw if the abort method is called when a write is not
 currently under way, while the reading object does not throw.

 The behaviors should be consistent.  I don't particularly care either way,
 but I believe Jonas would like to change FileReader to match
 File[Saver|Writer].

 - Kyle

Re: [FileAPI] File.slice spec bug

[Kyle Huey]

File.slice was first supported in Firefox 4.

- Kyle

On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote:

 The biggest concern is that this is a breaking change and quite a few web
 applications have already been using it. As far as I know, File.slice(start,
 length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3
 is supporting it. How do we communicate with web developers about this
 breaking change if we decide to make the change?

 Jian


 On Tue, Apr 12, 2011 at 11:34 AM, Arun Ranganathan a...@mozilla.comwrote:

 On 4/12/11 2:24 PM, Jonas Sicking wrote:

 Hi All,

 It was recently (yesterday) pointed out to me that we let a bad
 spec-bug slip through for File.slice. It doesn't match the argument
 semantics of Array.slice which can be very confusing for developers.

 In Array.slice the second argument is the index of the last item to be
 included in the returned slice.
 In File.slice the second argument is the number of bytes included in
 the returned slices.

 In other words, it's Array.slice(start, end), but File.slice(start,
 length).

 Additionally, in Array.slice the second argument is optional.

 File.slice is currently shipped by Chrome and Firefox 4. I would be
 fine with fixing this in Firefox 4.0.1, however that only makes sense
 if the chrome folks are fine with fixing it in their implementation.

 So consider this an official request, would chrome be ok with changing
 the spec here?

 / Jonas


 I'm bummed that we collectively let this slip through the cracks, and
 personally think it's early enough to fix it.  But we should also decide how
 closely to match Array.slice.  Should we allow code of the sort

 file.slice(-80)?

 Code of that sort is allowed with Array.slice.

 MDC has good developer docs about what's in Firefox for Array.slice:


 https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/slice

 Developers may have already discovered file.slice (e.g. see
 http://hacks.mozilla.org/2011/04/resumeupload/), so fixing this will
 involve some messaging.

 -- A*

[FileAPI] BlobBuilder.getBlob should clear the BlobBuilder

[Kyle Huey]

Hello All,

In the current FileAPI Writer spec a BlobBuilder can be used to build a
series of blobs like so:

  var bb = BlobBuilder();
  bb.append(foo);
  var foo = bb.getBlob();
  bb.append(bar);
  var bar = bb.getBlob();
  foo.size; // == 3
  bar.size; // == 6

My concern with this pattern is that it seems that one of the primary use
cases is to keep a BlobBuilder around for a while to build up a blob over
time.  A BlobBuilder left around could potentially entrain large amounts of
memory.  I propose that BlobBuilder.getBlob() clears the BlobBuilder,
returning it to an empty state.  The current behavior also doesn't seem
terribly useful to me (though I'm happy to be convinced otherwise) and be
easily replicated on top of the proposed behavior (immediately reappending
the Blob that was just retrieved.)

Thoughts/comments?

- Kyle