XHR.responseBlob and BlobWriter [nee FileWriter]

[Eric Uhrhane]

The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest?  Here's my proposal [built
mainly from the good ideas other folks posted in the original thread].

Use case 1: the developer wants to download a Blob of data, use it for
a while [e.g. slicing out sub-Blobs and displaying them as images],
then have it go away automatically.
Use case 2: the developer wants to download a Blob of data, saving it
in a location of the user's choice outside the sandbox.
Use case 3: the developer wants to download a Blob of data, save it in
the sandboxed FileSystem, and access it again later.

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.  Call this
wantBlob for now, although a better name would be appreciated.
If wantBlob is set, responseBlob will be valid when the XHR completes,
and responseText and responseXML will be null.
If wantBlob is not set, responseBlob will be null, and the XHR will
function as it does now.

When wantBlob is set, on all progress events before the XHR is
complete, responseBlob will be null.  As of completion, it will return
a Blob containing the full contents of the download.  [We could later
add incremental Blobs in progress events, but let's keep this simple
to start with.]

This satisfies use case 1 as-is.
With the BlobWriter spec [2], as currently written [assuming we agree
on how to get our hands on a BlobWriter], it takes care of use case 2.
With the FileSystem spec [3], as currently written, it takes care of use case 3.

I think this takes care of the major use cases, doesn't force anyone
to implement FileSystem to solve the cases that don't really require
it, removes any need for synchronous IO, and is pretty simple for
developers to understand and use.  What do you think?

   Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0313.html
[2] http://dev.w3.org/2009/dap/file-system/file-writer.html
[3] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html

Re: [IndexedDB] Computed indexes

[Shawn Wilsher]

 On 6/28/2010 4:59 PM, Jeremy Orlow wrote:

Gotcha.  Yeah, this technique can be used to replace any use case for
explicitly managed indexes.  And, for that reason, I think we should just
get rid of them now.

Agreed.


As for whether we should have a feature to compute index keys via
a function: I think we should put it on it on the back burner for now, but
use your proposal as the starting when we re-examine it.  I'd like to do
this after there's a working implementation in the wild that developers can
play with so we can address the biggest pain points--rather than just going
on our intuition.  If this does get punted past v1, I'd definitely like to
see it addressed in v2 though.
Once Firefox ships a beta for 4.0 (likely late this week or early next) 
we'll have something in the wild.  Nightlies currently have it (although 
we haven't been pushing it much).


Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [File API] Recent Updates To Specification + Co-Editor

[Jonas Sicking]

On Mon, Jun 28, 2010 at 4:01 PM, Arun Ranganathan  wrote:
> On 6/28/10 3:41 PM, Alexey Proskuryakov wrote:
>>
>> 28.06.2010, в 15:37, Adam Barth написал(а):
>>
>>> I believe Alexey Proskuryakov has strong feelings on this topic.
>>
>>
>> I e-mailed public-webapps not long ago, but that seems to have gone
>> unnoticed,
>> .
>
> Alexey: sorry if I overlooked responding to your original note.  FWIW, we
> should separate URL/url and FileReader/BlobReader, since they are separate
> discussions.
>
> 1. URL vs. url: I agree that consistency is desirable, but almost *all*
> attributes *except constants* are expressed as lower case.  URL/url is an
> exception (I'm very happy we gave up the *far* more confusing URN/urn -- I'm
> sorry I even considered it ;-)).  I don't have a very strong opinion, so
> I'll defer to those that do, but to your point, Firefox also does ship
> 'document.URL' which seems likely the most common use of this property
> amongst authors.  We don't *also* ship 'document.url.'  My recollection is
> that Hixie changed a few things a while ago already, but I can't find a
> reference in email.  This is bikeshedding to a certain extent, since
> developers will defer to documentation about attribute names.  Given that a
> change has *already* occurred, do you *really* feel strongly enough to
> protest the change?

Right, this is completely orthogonal to the FileReader/BlobReader naming issue.

> 2. FileReader/BlobReader: I have a stronger opinion on this subject.  Blob
> hasn't really "landed" on the web in a big way yet.  Firefox's
> implementation doesn't do Blob, although we do File.  While renaming the
> object BlobReader does account for the fact that all the arguments to the
> read methods are Blob arguments, there hasn't been too much discussion of
> what the "majority use case" will be.  By "majority use case" I mean, what
> the object will be *mostly* used for.  *Right now* Jonas points out that the
> majority use case is with Files.  A good reason to rename it is if use cases
> emerge that are so compelling that manipulating Blob data generally might be
> just as desirable as manipulating user-selected files from the underlying
> file system.  Can you or anyone cite such use cases?
>
> In either case, we're agitating on behalf of web developers.  Having some
> weigh in would be useful in an implementor's bike-shedathon :-)

Would definitely like to hear developer feedback.

/ Jonas

Re: [IndexedDB] Computed indexes

[Jeremy Orlow]

On Tue, Jun 29, 2010 at 7:21 AM, Jonas Sicking  wrote:

> I'm pretty convinced that complex indexes is something that people
> need to do. However it's entirely possible that simply using a
> separate objectStore is good enough for v1. More details below.
>
> >> Though maybe people can use separate objectStores which hold computed
> >> values. That might certainly be good enough for version 1. I'll have
> >> to think more about that.
> >
> > HmmmI'm not sure I follow.  Could you explain more thoroughly?
>
> To bring back an old example. Say that you're storing objects like
>
> { name: "Elvis", born: "January 8, 1935", died: "August 16, 1977" }
> { name: "Gustav III", born: "24 January 1746", died: "29 March 1792" }
> { name: "Benny Andersson", born: "16 December 1946" }
>
> and want to index on the age-at-death. What you'd do is that you set
> up a separate objectStore using the following calls:
>
> store = createObjectStore("AgeAtDeathStoreIndex", "name", false);
> store.createIndex("ageIndex", "age", false);
>
> When the above three objects are stored, you also store the following
> two object into the "AgeAtDeathStoreIndex" objecStore:
>
> { name: "Elvis", age: 42 }
> { name: "Gustav III", age: 46 }
>
> You can then easily search based on age at death by first looking
> something up in the ageIndex and then looking up the found name in the
> original objecStore. Something like:
>
> // only finds one person
> trans = db.transaction(["people", "AgeAtDeathStoreIndex"]);
>
> trans.objectStore("AgeAtDeathStoreIndex").index("ageIndex").get(42).onsuccess
> = function(e) {
>  trans.objectStore("people").get(e.value).onsuccess = function(e) {
>alert(e.value.name + " was 42 at time of death");
>  }
> }
>
> This is certainly more work, but at least it avoids *forcing* us to
> put anything into v1 of IndexedDB.
>

Gotcha.  Yeah, this technique can be used to replace any use case for
explicitly managed indexes.  And, for that reason, I think we should just
get rid of them now.

As for whether we should have a feature to compute index keys via
a function: I think we should put it on it on the back burner for now, but
use your proposal as the starting when we re-examine it.  I'd like to do
this after there's a working implementation in the wild that developers can
play with so we can address the biggest pain points--rather than just going
on our intuition.  If this does get punted past v1, I'd definitely like to
see it addressed in v2 though.

J

Re: [File API] Recent Updates To Specification + Co-Editor

[Arun Ranganathan]

On 6/28/10 3:41 PM, Alexey Proskuryakov wrote:


28.06.2010, в 15:37, Adam Barth написал(а):


I believe Alexey Proskuryakov has strong feelings on this topic.



I e-mailed public-webapps not long ago, but that seems to have gone 
unnoticed, 
.


Alexey: sorry if I overlooked responding to your original note.  FWIW, 
we should separate URL/url and FileReader/BlobReader, since they are 
separate discussions.


1. URL vs. url: I agree that consistency is desirable, but almost *all* 
attributes *except constants* are expressed as lower case.  URL/url is 
an exception (I'm very happy we gave up the *far* more confusing URN/urn 
-- I'm sorry I even considered it ;-)).  I don't have a very strong 
opinion, so I'll defer to those that do, but to your point, Firefox also 
does ship 'document.URL' which seems likely the most common use of this 
property amongst authors.  We don't *also* ship 'document.url.'  My 
recollection is that Hixie changed a few things a while ago already, but 
I can't find a reference in email.  This is bikeshedding to a certain 
extent, since developers will defer to documentation about attribute 
names.  Given that a change has *already* occurred, do you *really* feel 
strongly enough to protest the change?


2. FileReader/BlobReader: I have a stronger opinion on this subject.  
Blob hasn't really "landed" on the web in a big way yet.  Firefox's 
implementation doesn't do Blob, although we do File.  While renaming the 
object BlobReader does account for the fact that all the arguments to 
the read methods are Blob arguments, there hasn't been too much 
discussion of what the "majority use case" will be.  By "majority use 
case" I mean, what the object will be *mostly* used for.  *Right now* 
Jonas points out that the majority use case is with Files.  A good 
reason to rename it is if use cases emerge that are so compelling that 
manipulating Blob data generally might be just as desirable as 
manipulating user-selected files from the underlying file system.  Can 
you or anyone cite such use cases?


In either case, we're agitating on behalf of web developers.  Having 
some weigh in would be useful in an implementor's bike-shedathon :-)


-- A*

Re: [File API] Recent Updates To Specification + Co-Editor

[Alexey Proskuryakov]

28.06.2010, в 15:37, Adam Barth написал(а):


I believe Alexey Proskuryakov has strong feelings on this topic.



I e-mailed public-webapps not long ago, but that seems to have gone  
unnoticed, .


- WBR, Alexey Proskuryakov

Re: [File API] Recent Updates To Specification + Co-Editor

[Adam Barth]

On Mon, Jun 28, 2010 at 3:20 PM, Jonas Sicking  wrote:
> On Mon, Jun 28, 2010 at 3:06 PM, Anne van Kesteren  wrote:
>> On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking  wrote:
>>> I certainly agree that anyone shipping an implementation before a spec
>>> is an official Recommendation is always running the risk of running in
>>> to incompatible changes. However in the past we have avoided to break
>>> existing implementations, and I certainly can't think of a time we've
>>> decided to do it over what is essentially a bikeshed issue.
>>
>> Recently on your account a bunch of attributes named URL became url while
>> they were already deployed in browsers based on WebKit. ;-)
>
> First of all, iirc there was already internal inconsistency in that
> webkit shipped properties named both .url and .URL. And so if the
> webkit devs wanted consistent naming, which seemed like a priority for
> everyone.
>
> Second, the "url"/"URL" name is much less likely to be used by
> existing content than the the "FileReader"/"BlobReader" name. It is
> quite possible to use EventSource and WebSockets without ever using
> the "url"/"URL" name, however it is impossible to use a FileReader
> without using the "FileReader" name.
>
> Third, I don't believe anyone raised the concern that there was likely
> content out there depending on the existing name.

I believe Alexey Proskuryakov has strong feelings on this topic.

Adam

Re: [File API] Recent Updates To Specification + Co-Editor

[Jonas Sicking]

On Mon, Jun 28, 2010 at 3:06 PM, Anne van Kesteren  wrote:
> On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking  wrote:
>>
>> I certainly agree that anyone shipping an implementation before a spec
>> is an official Recommendation is always running the risk of running in
>> to incompatible changes. However in the past we have avoided to break
>> existing implementations, and I certainly can't think of a time we've
>> decided to do it over what is essentially a bikeshed issue.
>
> Recently on your account a bunch of attributes named URL became url while
> they were already deployed in browsers based on WebKit. ;-)

First of all, iirc there was already internal inconsistency in that
webkit shipped properties named both .url and .URL. And so if the
webkit devs wanted consistent naming, which seemed like a priority for
everyone.

Second, the "url"/"URL" name is much less likely to be used by
existing content than the the "FileReader"/"BlobReader" name. It is
quite possible to use EventSource and WebSockets without ever using
the "url"/"URL" name, however it is impossible to use a FileReader
without using the "FileReader" name.

Third, I don't believe anyone raised the concern that there was likely
content out there depending on the existing name.

/ Jonas

Re: [File API] Recent Updates To Specification + Co-Editor

[Anne van Kesteren]

On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking  wrote:

I certainly agree that anyone shipping an implementation before a spec
is an official Recommendation is always running the risk of running in
to incompatible changes. However in the past we have avoided to break
existing implementations, and I certainly can't think of a time we've
decided to do it over what is essentially a bikeshed issue.


Recently on your account a bunch of attributes named URL became url while  
they were already deployed in browsers based on WebKit. ;-)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [File API] Recent Updates To Specification + Co-Editor

[Jonas Sicking]

On Mon, Jun 28, 2010 at 2:44 PM, Eric Uhrhane  wrote:
> On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan  wrote:
>> Greetings WebApps WG,
>>
>> I have made edits to the File API specification [1].  There are a few things
>> of note that I'd like to call the WG's attention to.
>>
>> 1. There is a name change in effect.  FileReader has been re-named
>> BlobReader, upon request from Chrome team folks[2][3].  The name
>> "BlobReader" won't win awards in a beauty pageant, but it tersely describes
>> an object to read Blobs (which could originate from the underlying file
>> system *or* be generated *within* a Web App).  My present understanding is
>> that FileWriter will also undergo a name change.  Naming is really hard.
>>  Firefox already ships with FileReader, but I see the point of having an
>> object named for what it does, which in this case is certainly more than
>> file reading from the underlying file system.  I also abhor bike shedding,
>> especially over naming, but this is something that's exposed to the authors.
>>  I have not renamed FileError or FileException.  In the case of errors and
>> exceptions, I think *most* scenarios will occur as a result of issues with
>> the underlying file system.  These names should remain.
>
> I've just made the corresponding changes to FileWriter [->BlobWriter]
> in both the FileWriter and FileSystem specs.  I've not changed the URL
> of the FileWriter spec, though, for simplicity.

I have to say, I'm not a big fan of these name changes for two reasons:

1. While technically speaking, the functions on FileReader/BlobReader
does accept Blobs rather than Files, I suspect that in most cases
people will be dealing with files. I.e. I think it will be far more
common that the Blob being passed in to the reader is in fact also a
File, and is thought of by the developer as a file, than not. So while
it seems strange to use a FileReader to read a Blob, it feels equally
foreign to use a BlobReader to read a file.

2. Firefox 3.6 is already shipping with a FileReader implementation.
Large parts of the spec remained stable and without request for
changes for quite a while and we deemed it unlikely to change. Indeed,
no other changes have been requested, other than the name change, in
the parts that we implemented.

I certainly agree that anyone shipping an implementation before a spec
is an official Recommendation is always running the risk of running in
to incompatible changes. However in the past we have avoided to break
existing implementations, and I certainly can't think of a time we've
decided to do it over what is essentially a bikeshed issue.

/ Jonas

Re: Updates to File API

[Arun Ranganathan]

On 6/23/10 9:50 AM, Jian Li wrote:
I think encoding the security origin in the URL allows the UAs to do 
the security origin check in place, without routing through other 
authority to get the origin information that might cause the check 
taking long time to finish.


If we worry about showing the double schemes in the URL, we can 
transform the origin encoded in the URL by using base64 or other 
escaping algorithm.


Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url 
allows you to do that, without obliging other UAs to do that.  Some UAs 
may elect to use "smart caching" to accomplish the same kinds of things, 
without tagging the URL with origin information.  Others may see benefit 
in origin-tagging.


I've reconsidered trying to architect a scheme that allows all use-case 
scenarios for blob: URIs.


-- A*


Jian


On Wed, Jun 23, 2010 at 8:24 AM, David Levin > wrote:


On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman
mailto:adria...@microsoft.com>> wrote:

On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
> I agree with you Adrian that it makes sense to let the user
agent figure
> out the optimal way of implementing origin and other checks.
>
> A logical step from that premise is that the choice/format
of the
> namespace specific string should be left up to the UA as
embedding
> information in there may be the optimal way for some UA's of
implementing
> said checks, and it sounds like other UAs may not want to do
that.

Robin outlined why that would be a problem [1]. My original
feeling was that this should be left up to UAs, as you say,
but I've been convinced that doing so is a race to the most
complex URL scheme.


Robin discussed something that could possibly in
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At
the same time, there are implementors who gave specific reasons
why encoding certain information (scheme, host, port) in
the namespace specific string (NSS) is useful to various UAs. No
other information has been requested, so theories adding more
information seem premature.

If the format must be specified, it seems reasonable to take both
the theoretical and practical issues into account.

Encoding that the security origin in the NSS isn't complex. If a
proposal is needed about how that can be done in a simple way, I'm
willing to supply one. Also, UAs that don't care about that
information are free to ignore it and don't need to parse it.

dave

Re: [File API] Recent Updates To Specification + Co-Editor

[Eric Uhrhane]

On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan  wrote:
> Greetings WebApps WG,
>
> I have made edits to the File API specification [1].  There are a few things
> of note that I'd like to call the WG's attention to.
>
> 1. There is a name change in effect.  FileReader has been re-named
> BlobReader, upon request from Chrome team folks[2][3].  The name
> "BlobReader" won't win awards in a beauty pageant, but it tersely describes
> an object to read Blobs (which could originate from the underlying file
> system *or* be generated *within* a Web App).  My present understanding is
> that FileWriter will also undergo a name change.  Naming is really hard.
>  Firefox already ships with FileReader, but I see the point of having an
> object named for what it does, which in this case is certainly more than
> file reading from the underlying file system.  I also abhor bike shedding,
> especially over naming, but this is something that's exposed to the authors.
>  I have not renamed FileError or FileException.  In the case of errors and
> exceptions, I think *most* scenarios will occur as a result of issues with
> the underlying file system.  These names should remain.

I've just made the corresponding changes to FileWriter [->BlobWriter]
in both the FileWriter and FileSystem specs.  I've not changed the URL
of the FileWriter spec, though, for simplicity.

> 2. I've updated the URL scheme for Blobs using an ABNF that calls for an
> "opaque string" which is a term I define in the specification.  There was
> much discussion about this aspect of the File API specification, and I think
> the existing scheme does allow for user agents to tack on origin information
> in the URL (this is not something the spec. says you should do).  The actual
> choice of opaque string is left to implementations, though the specification
> suggests UUID in its canonical form (and provides an ABNF for this).  I
> think this is the most any specification has said on the subject of URLs.
>
> 3. There is an additional asynchronous read method on BlobReader, and an
> additional synchronous read method on BlobReaderSync, namely
> readAsArrayBuffer.  These use the TypedArrays definition initially defined
> by the WebGL WG [4].
>
> 4. I am moving on from my full-time role at Mozilla to a part-time
> consulting role.  I'll continue to be an editor of the File API, but I am
> stepping down as Chair of the WebGL WG.  I'll continue to be active in
> standards communities, though :-)
>
> 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of
> the File API specification.  Most people who work on HTML5 and WebApps know
> Jonas' contributions to both WGs; with everyone's consent, I'd like to
> nominate him as co-editor.  His model for an asynchronous event-driven API
> is what prompted the initial rewrite, and he also works on both File API and
> IndexedDB implementation (amongst other things).

Sounds good.  Thanks Jonas!

> -- A*
>
> [1] http://dev.w3.org/2006/webapi/FileAPI/
> [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
> [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
> [4]
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
>
>

Re: Updates to File API

[Arun Ranganathan]

Hi Dave,


On 6/23/10 8:24 AM, David Levin wrote:
On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman 
mailto:adria...@microsoft.com>> wrote:


On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
> I agree with you Adrian that it makes sense to let the user
agent figure
> out the optimal way of implementing origin and other checks.
>
> A logical step from that premise is that the choice/format of the
> namespace specific string should be left up to the UA as embedding
> information in there may be the optimal way for some UA's of
implementing
> said checks, and it sounds like other UAs may not want to do that.

Robin outlined why that would be a problem [1]. My original
feeling was that this should be left up to UAs, as you say, but
I've been convinced that doing so is a race to the most complex
URL scheme.


Robin discussed something that could possibly in 
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At 
the same time, there are implementors who gave specific reasons 
why encoding certain information (scheme, host, port) in the namespace 
specific string (NSS) is useful to various UAs. No other information 
has been requested, so theories adding more information seem premature.




If the format must be specified, it seems reasonable to take both the 
theoretical and practical issues into account.




I agree that both theoretical and practical issues should be taken into 
account.  While I was initially in favor of a uniform URL format for 
blob: URLs, after following this discussion I came up with:


http://dev.w3.org/2006/webapi/FileAPI/#url

This allows a few things that I think the WG has discussed as desirable:

1. The scheme consists of an opaque string, which I recommend is like 
UUID in its canonical form.  The scheme does not disallow the inclusion 
of origin information in the URL, though I personally think 
implementations could use "smart caching" and not necessarily use the 
scheme to store this information.


2. The scheme allows for fragment identifiers, which are applicable on a 
media-type basis to the Blob being accessed.


It was clear that a "one size fits all" wouldn't be desirable.  I think 
*generally speaking* the actual blob: URL is hidden from authors, who 
won't have cause to interact with format, and this is why I chose to 
specify this the way I have.


Encoding that the security origin in the NSS isn't complex. If a 
proposal is needed about how that can be done in a simple way, I'm 
willing to supply one. Also, UAs that don't care about that 
information are free to ignore it and don't need to parse it.




I think it might be useful to supply one, but my instinct is that this 
does not need to be part of the specification.


-- A*

Re: [IndexedDB] Computed indexes

[Jonas Sicking]

I trimmed this thread quite a bit since there now seems to be less
talking past each other. Feel free to bring back any part if you think
I've trimmed too agressively.

>> >> > What is the difference between an "expressionIndex" and a keyPath?
>> >> >  It
>> >> > seems
>> >> > like they're doing about the same thing.  My proposal to allow
>> >> > keyPath
>> >> > to be
>> >> > artibrary JavaScript and then have the value being inserted be the
>> >> > global
>> >> > scope actually sounds almost identical to what you're doingexcept
>> >> > more
>> >> > in the relm of what JS engines already do (since it's much like an
>> >> > eval).
>> >>
>> >> It is about the same thing yes. Though presumably an implementation
>> >> could optimize "evaluating" the keyPath heavily. Much more so than a
>> >> generic expression.
>> >
>> > Howso?  Any implementation should be able to cache the compiled/JITed
>> > form
>> > of the string passed into it's internal implementation of eval.
>>
>> Executing a complied expression, including firing up all the contexts
>> needed to run a piece of javascript, is at least in the firefox js
>> engine, significantly more expensive than simply grabbing the relevant
>> value as you serialize the javascript object into the database.
>>
>> Additionally, for a simple keyPath you don't have to worry about
>> cloning objects or implementing copy-on-write semantics.
>>
>> Finally, you can perform optimizations such as not updating indexes if
>> you notice that the relevant property doesn't change during calls to
>> objectStore.put() and cursor.update().
>>
>> All in all I think keyPaths are preferrable when they are possible.
>> Full on expressions will likely always be slower and more cumbersome,
>> but they seem better than the alternatives when the value isn't stored
>> directly in the stored object.
>
> Ahh!  I think I see why we're both having so hard of a time understanding
> each other.  I've been talking about various proposals for what keyPath
> would be and you're talking about a proposal that'd be in addition to some
> "simple" keyPath proposal (that could easily have the properties you just
> mentioned above).  That explains a lot.
> I definitely like the idea of some simple keyPath concept optionally
> augmented by a more complex one that can actually calculate the key--whether
> represented as a function body or an expression.

Cool! Lets attempt to hash out the details then :)

>> > And as long as there are
>> > fundamental reasons why one can't be optimized, implementational
>> > challenges
>> > really shouldn't impact how we design the API.  At all.
>> > Anyway, I'll continue thinking about this, but I'm far from convinced
>> > that
>> > allowing javascript (whether it's like the body of a function or like
>> > it's
>> > evaled) is necessary for v1.  It adds a lot of complexity and I honestly
>> > doubt we understand the problems well enough at the moment to come up
>> > with
>> > the best solution.  I'd much rather punt for now.  But if you feel
>> > strongly
>> > we need this for v1, I think we need to find some examples in SQL or
>> > other
>> > database engines to base our implementation on.  Otherwise we're
>> > building an
>> > API on top of a tower of assumptions.
>>
>> I'd prefer to leave expressions out of v1 as well. However I would be
>> worried about leaving out the ability to index on computed values
>> entirely. I.e. remove the ability to index on anything that isn't a
>> plain value in the stored object. And it doesn't seem like there is
>> much support for the way that the spec supports them now which is
>> through explicit calls to add/remove items out of an index.
>
> I definitely think we need to remove the concept of managing an index
> manually.

I agree. Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10027

> Whether it's worth putting this in v1 or adding some way to
> provide index values when doing an objectStore.put/add/etc, I'm honestly not
> sure.
> To be honest, I don't think any of the use cases presented so far are a slam
> dunk for the need to support computed indexes (vs. just making someone store
> the computed value in the object store value itself and then indexing with a
> simple keyPath), but I definitely do think it'll be a useful feature.  And
> it sounds like you guys are pretty convinced of its importance, so I'm happy
> to go along with it.

I'm pretty convinced that complex indexes is something that people
need to do. However it's entirely possible that simply using a
separate objectStore is good enough for v1. More details below.

>> Though maybe people can use separate objectStores which hold computed
>> values. That might certainly be good enough for version 1. I'll have
>> to think more about that.
>
> HmmmI'm not sure I follow.  Could you explain more thoroughly?

To bring back an old example. Say that you're storing objects like

{ name: "Elvis", born: "January 8, 1935", died: "August 16, 1977" }
{ name: "Gustav III", bo

[File API] Recent Updates To Specification + Co-Editor

[Arun Ranganathan]

Greetings WebApps WG,

I have made edits to the File API specification [1].  There are a few 
things of note that I'd like to call the WG's attention to.


1. There is a name change in effect.  FileReader has been re-named 
BlobReader, upon request from Chrome team folks[2][3].  The name 
"BlobReader" won't win awards in a beauty pageant, but it tersely 
describes an object to read Blobs (which could originate from the 
underlying file system *or* be generated *within* a Web App).  My 
present understanding is that FileWriter will also undergo a name 
change.  Naming is really hard.  Firefox already ships with FileReader, 
but I see the point of having an object named for what it does, which in 
this case is certainly more than file reading from the underlying file 
system.  I also abhor bike shedding, especially over naming, but this is 
something that's exposed to the authors.  I have not renamed FileError 
or FileException.  In the case of errors and exceptions, I think *most* 
scenarios will occur as a result of issues with the underlying file 
system.  These names should remain.


2. I've updated the URL scheme for Blobs using an ABNF that calls for an 
"opaque string" which is a term I define in the specification.  There 
was much discussion about this aspect of the File API specification, and 
I think the existing scheme does allow for user agents to tack on origin 
information in the URL (this is not something the spec. says you should 
do).  The actual choice of opaque string is left to implementations, 
though the specification suggests UUID in its canonical form (and 
provides an ABNF for this).  I think this is the most any specification 
has said on the subject of URLs.


3. There is an additional asynchronous read method on BlobReader, and an 
additional synchronous read method on BlobReaderSync, namely 
readAsArrayBuffer.  These use the TypedArrays definition initially 
defined by the WebGL WG [4].


4. I am moving on from my full-time role at Mozilla to a part-time 
consulting role.  I'll continue to be an editor of the File API, but I 
am stepping down as Chair of the WebGL WG.  I'll continue to be active 
in standards communities, though :-)


5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor 
of the File API specification.  Most people who work on HTML5 and 
WebApps know Jonas' contributions to both WGs; with everyone's consent, 
I'd like to nominate him as co-editor.  His model for an asynchronous 
event-driven API is what prompted the initial rewrite, and he also works 
on both File API and IndexedDB implementation (amongst other things).


-- A*

[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html
[4] 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html

[Bug 10027] New: Remove explicit add/remove functions from IDBIndex

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10027

   Summary: Remove explicit add/remove functions from IDBIndex
   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


The spec currently allows entries to be manually added and removed from
indexes. While this is one solution to the problem of indexing on computed
values, it's not one that seems very popular.

There are currently a few other proposals that have been made for example [1]
and [2].

Until we figure out how to do more complex indexes, I propose we remove the
add/put/remove functions from IDBIndex. Similarly I propose that calling
update() on a cursor opened using IDBIndex.openCursor is not allowed.

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0882.html

-- 
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: [IndexedDB] Syntax for opening a cursor

[Nikunj Mehta]

Hi Jeremy,

I have been able to push my changes (after more Mercurial server problems) just 
now. I reopened 9790 because Andrei's commit made IDBCursor and IDBObjectStore 
constants unavailable from the global object. After all this, you should be 
able to do the following for your need below:

myObjectStore.openCursor(IDBKeyRange.leftBound("key"), 
IDBCursor.NEXT_NO_DUPLICATE);

Nikunj
On Jun 25, 2010, at 4:25 AM, Jeremy Orlow wrote:

> If I'm reading the current spec right (besides the "[NoInterfaceObject]" 
> attributes that I thought Nikunj was going to remove), if I want to open a 
> cursor, this is what I need to do:
> 
> myObjectStore.openCursor(new IDBKeyRange().leftBound("key"), new 
> IDBCursor().NEXT_NO_DUPLICATE);
> 
> Note that I'm creating 2 objects which get thrown away after using the 
> constructor and constant.  This seems pretty wasteful.
> 
> Jonas' proposal (which I guess Nikunj is currently in the middle of 
> implementing?) makes things a bit better:
> 
> myObjectStore.openCursor(window.indexedDB.makeLeftBoundedKeyRange("key"), new 
> IDBCursor().NEXT_NO_DUPLICATE);
> 
> or, when you have a single key that you're looking for, you can use the short 
> hand
> 
> myObjectStore.openCursor("key", new IDBCursor().PREV);
> 
> But even in these examples, we're creating a needless object.  I believe we 
> could also use the prototype to grab the constant, but the syntax is still 
> pretty verbose and horrid.
> 
> Can't we do better?
> 
> J