Re: [indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

[Jeremy Orlow]

We should probably just remove the special case.  I believe WebIDL specifies
that a null would then turn into the string "null".  This is what we've done
pretty much everywhere else I believe.

J

On Mon, Jun 6, 2011 at 7:23 PM, Israel Hilerio wrote:

> The parameter of IDBDatabase.setVersion is defined in the WebIDL as
> [TreatNullAs=EmptyString] but in the method definition it says that the
> parameter cannot be nullable.  Do we want to enable null values?
>
> Israel
>
>

Re: [Indexeddb} Bug # 9653 - nullable violations on parameters

[Jonas Sicking]

On Mon, Jun 6, 2011 at 7:19 PM, Israel Hilerio  wrote:
> On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote:
>> On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack 
>> wrote:
>> > Jonas Sicking:
>> >> However it appears that that extended attribute is not present in
>> >> newer versions of the WebIDL spec. Cameron, is this something that is
>> >> planned to be brought back? It seems like a useful feature to avoid
>> >> having to define in prose this rather common requirement. We should
>> >> also define which exception should be thrown if such a [NoNull]
>> >> requirement was violated.
>> >
>> > I plan to make object types non-nullable by default, and to allow null
>> > you would write "MyInterface?".
>> >
>> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640.
>> >
>> > I will most likely make passing in null for a non-nullable object type
>> > result in a TypeError being thrown.
>>
>> Excellent! I think that should mean that no changes are needed to the
>> IndexedDB spec at all. I can't think of any instances where we use specific
>> interface names while still accepting null values.
>>
>> / Jonas
>>
>> / Jonas
>
> Based on this conversation, we agreed that we wanted to throw a TypeError 
> when a non-nullable parameter was passed a null argument.  This implies to 
> me, for example, that if we were to pass a null value for the key parameter 
> of IDBObjectStore.put we will throw a TypeError (i.e. InvalidArgument).  
> We're assuming this Exception takes precedence over any IDB Exceptions (i.e. 
> DATA_ERR).
>
> This seems like a common pattern we want to enforce everywhere, throwing a 
> TypeError before any type of IDBError when passing null to non-nullable 
> arguments.  Do you agree?

Yes.

> The reason I'm asking is that we found FireFox does this a little different.  
> They are throwing a DATA_ERR when passing null as a key value.  I just want 
> to make sure we're on the same page.

I expect that we'll end up having to change lots of exceptions in the
Firefox implementation.

/ Jonas

[indexeddb] IDBDatabase.setVersion non-nullable parameter has a default for null

[Israel Hilerio]

The parameter of IDBDatabase.setVersion is defined in the WebIDL as 
[TreatNullAs=EmptyString] but in the method definition it says that the 
parameter cannot be nullable.  Do we want to enable null values?

Israel

RE: [Indexeddb} Bug # 9653 - nullable violations on parameters

[Israel Hilerio]

On Tue, Apr 26, 2011 at 10:05 PM, Jonas Sicking wrote:
> On Tue, Apr 26, 2011 at 8:23 PM, Cameron McCormack 
> wrote:
> > Jonas Sicking:
> >> However it appears that that extended attribute is not present in
> >> newer versions of the WebIDL spec. Cameron, is this something that is
> >> planned to be brought back? It seems like a useful feature to avoid
> >> having to define in prose this rather common requirement. We should
> >> also define which exception should be thrown if such a [NoNull]
> >> requirement was violated.
> >
> > I plan to make object types non-nullable by default, and to allow null
> > you would write "MyInterface?".
> >
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640.
> >
> > I will most likely make passing in null for a non-nullable object type
> > result in a TypeError being thrown.
> 
> Excellent! I think that should mean that no changes are needed to the
> IndexedDB spec at all. I can't think of any instances where we use specific
> interface names while still accepting null values.
> 
> / Jonas
> 
> / Jonas

Based on this conversation, we agreed that we wanted to throw a TypeError when 
a non-nullable parameter was passed a null argument.  This implies to me, for 
example, that if we were to pass a null value for the key parameter of 
IDBObjectStore.put we will throw a TypeError (i.e. InvalidArgument).  We're 
assuming this Exception takes precedence over any IDB Exceptions (i.e. 
DATA_ERR).

This seems like a common pattern we want to enforce everywhere, throwing a 
TypeError before any type of IDBError when passing null to non-nullable 
arguments.  Do you agree?

The reason I'm asking is that we found FireFox does this a little different.  
They are throwing a DATA_ERR when passing null as a key value.  I just want to 
make sure we're on the same page.

Israel

[File API: FileSystem] Removed mimeType from toURL

[Eric U]

The optional mimeType parameter to Entry[Sync].toURL is redundant with
url.createObjectURL.  It also doesn't work with the URL format
proposed in the notes and now implemented in Chromium.  I have removed
it from the spec.

 Eric

Re: WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

[Aryeh Gregor]

On Mon, Jun 6, 2011 at 4:28 PM, Web Applications Working Group Issue
Tracker  wrote:
> FileError [1] and FileException [2] both define a DOMString attribute called 
> name that contains the name of the error/exception constant as a string. 
> Since this is not a useful "human readable" error message, and developers 
> should be encouraged to write code that compares against the code attribute, 
> it's not clear what the purpose of 'name' is. We'd prefer to remove it.

This matches the specification for DOMException:

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-name

For DOMException, every current browser except IE exposes the string
in some fashion.  Chrome 13 dev follows the DOM Core spec, Opera 11.11
has the same value under the message attribute, and Firefox 5.0a2 has
the value under the name attribute but prefixed with "NS_ERROR_".  In
IE9, the message attribute contains something like "DOM Exception:
HIERARCHY_REQUEST_ERR (3)", which is only marginally more
human-readable than just "HIERARCHY_REQUEST_ERR".

I'm not strongly attached to name, but we should have some
standardized string exposed as an attribute that contains the string
form of the error code, so authors who run into the exception will
have something to Google.  The numeric error code is only useful if
you know what code you're looking for in advance.  The string code is
useful so that you have something memorable to refer to it by, search
for, etc.  Also, if you're reading function documentation and it
describes what errors are thrown, it will normally use the string
code, not the numeric code, so if the object only contains the numeric
code it will be hard to figure out from the documentation which error
condition was hit.

Currently everyone exposes the string code somewhere or other on the
exception object, at least for DOMException (and FileException et al.
should match IMO).  The exact location and format just needs to be
standardized.  Maybe we could just standardize the message attribute,
since it seems like everyone puts *something* more or less
human-readable there?

Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

[Cameron McCormack]

Jonas Sicking:
> I don't know about other APIs. But it does seem very unfortunate to
> simply silently ignore unknown arguments to
> IDBDatabase.createObjectStore. Though then again, extra (and thus
> unknown) arguments are ignored to all other DOM calls.

Right (not as defined in Web IDL at the moment, but will be soon).

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

[Jonas Sicking]

On Mon, Jun 6, 2011 at 2:15 PM, Cameron McCormack  wrote:
> Jonas Sicking:
>> The one outstanding issue that I know about is that we want IndexedDB
>> to throw if any unknown parameters are specified. I don't know if
>> WebIDL dictionaries support those yet. Or if it's something that we
>> can specify in prose.
>
> I was waiting to see if anyone else had any views on that in the other
> thread, but I guess they don’t. :-)  I am still not quite comfortable
> with looking at the enumerability of the property to determine whether
> it will be used as a dictionary member value.  It’s not consistent with
> how property descriptors are handled by Object.defineProperty and it
> doesn’t seem like a natural JS usage pattern for objects-as-property-
> bags.

Yeah, I agree that using enumerability is not great.

> Throwing if there are unknown properties is also inconsistent with
> Object.defineProperty.  Do you think this should happen for all users of
> dictionaries (if other specs used them)?

I don't know about other APIs. But it does seem very unfortunate to
simply silently ignore unknown arguments to
IDBDatabase.createObjectStore. Though then again, extra (and thus
unknown) arguments are ignored to all other DOM calls.

/ Jonas

Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

[Cameron McCormack]

Jonas Sicking:
> The one outstanding issue that I know about is that we want IndexedDB
> to throw if any unknown parameters are specified. I don't know if
> WebIDL dictionaries support those yet. Or if it's something that we
> can specify in prose.

I was waiting to see if anyone else had any views on that in the other
thread, but I guess they don’t. :-)  I am still not quite comfortable
with looking at the enumerability of the property to determine whether
it will be used as a dictionary member value.  It’s not consistent with
how property descriptors are handled by Object.defineProperty and it
doesn’t seem like a natural JS usage pattern for objects-as-property-
bags.

Throwing if there are unknown properties is also inconsistent with
Object.defineProperty.  Do you think this should happen for all users of
dictionaries (if other specs used them)?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: Request for feedback: DOMCrypt API proposal - random number generation

[Yaron Sheffer]

  
  
In a "real" browser, there should indeed be enough entropy, mostly
from user actions. I don't know if this group cares about
server-side uses, but if it does, servers have a real problem
obtaining entropy. Especially in virtualized settings.

Thanks,
    Yaron

On 06/07/2011 12:00 AM, James Robinson wrote:

  On Mon, Jun 6, 2011 at 1:52 PM, Yaron
Sheffer 
wrote:

   Sure, that would be
much more efficient. And I agree with others on that thread
that the API should be non-blocking, non-failing, i.e. akin
to Linux /dev/urandom.

But my more important point was the second API: allow the
code to mix in any available entropy: keypresses, file
contents, plain old time, or externally obtained random
bytes (http://www.random.org/).
Maybe this API should be called "updateRandom", because it
does NOT determine the full state of the PRNG, which should
never be exposed. I would say this could be an optional API
(on Linux it simply amounts to writing bytes *into*
/dev/random, but I don't know if it's implementable on
Windows).
  



What's the use case for this?  Are you concerned that the
  browser's PRNG will not have sufficient randomness for your
  needs?


- James
 

   
Thanks,
     Yaron

  

On 06/06/2011 09:44 PM, Aryeh Gregor wrote:

  On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer  wrote:

  
However, I would like to propose one additional feature: a cryptographically
secure random number generator (CSRNG). This is a badly missed feature
today. [And just as I'm posting, I now see that Rich Tibbett beat me to this
idea.]

Specifically I would propose (and I know the details can be debated
forever):

random(): returns a cryptographically-strong 32-bit random integer.
setRandom(r): mixes a user-supplied random integer r into the RNG internal
state.

  
  This was discussed in February on whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030241.html

I didn't reread the whole thread, but my recollection is that people
preferred an API where you'd give it an ArrayBuffer and it would fill
it with random bytes.  That way you can efficiently get large amounts
of randomness.


  

  

  
  

  

[Bug 11113] [IndexedDB] The spec should be more explicit about the queuing of setVersion transactions

[bugzilla]

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

Eliot Graff  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Eliot Graff  2011-06-06 21:06:20 
UTC ---
Added the following sentence to IDBDatabaseSync.setVersion()

]]
Calling setVersion() while a first setVersion transaction is already running
queues up another setVersion transaction to run after the first setVersion
transaction is finished. 
[[

-- 
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: Request for feedback: DOMCrypt API proposal - random number generation

[James Robinson]

On Mon, Jun 6, 2011 at 1:52 PM, Yaron Sheffer  wrote:

> **
> Sure, that would be much more efficient. And I agree with others on that
> thread that the API should be non-blocking, non-failing, i.e. akin to Linux
> /dev/urandom.
>
> But my more important point was the second API: allow the code to mix in
> any available entropy: keypresses, file contents, plain old time, or
> externally obtained random bytes (http://www.random.org/). Maybe this API
> should be called "updateRandom", because it does NOT determine the full
> state of the PRNG, which should never be exposed. I would say this could be
> an optional API (on Linux it simply amounts to writing bytes *into*
> /dev/random, but I don't know if it's implementable on Windows).
>

What's the use case for this?  Are you concerned that the browser's PRNG
will not have sufficient randomness for your needs?

- James


>
> Thanks,
> Yaron
>
>
> On 06/06/2011 09:44 PM, Aryeh Gregor wrote:
>
> On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer  
>  wrote:
>
>  However, I would like to propose one additional feature: a cryptographically
> secure random number generator (CSRNG). This is a badly missed feature
> today. [And just as I'm posting, I now see that Rich Tibbett beat me to this
> idea.]
>
> Specifically I would propose (and I know the details can be debated
> forever):
>
> random(): returns a cryptographically-strong 32-bit random integer.
> setRandom(r): mixes a user-supplied random integer r into the RNG internal
> state.
>
>  This was discussed in February on whatwg:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030241.html
>
> I didn't reread the whole thread, but my recollection is that people
> preferred an API where you'd give it an ArrayBuffer and it would fill
> it with random bytes.  That way you can efficiently get large amounts
> of randomness.
>
>

Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

[Jonas Sicking]

On Mon, Jun 6, 2011 at 12:03 PM, Israel Hilerio  wrote:
> Have you considered using the WebIDL dictionary definition as a mechanism to 
> define the optional parameters in the IDBDatabase.createObjectStore method?
>
> Advantages at using the dictionary definition on WebIDL for optional 
> parameters:
> . Provides a fixed, ordered set of key-value pairs
> . Removes the need to walk the hierarchy chain to determine if these 
> attributes are available
> . Provides default values for each of its key-value pairs
> . Enables an extensible pattern to add new capabilities in the future
>
> I believe this will change our current method definition to the following:
>
> dictionary IDBOptionalParameters {
>    DOMString? keyPath = null;
>    boolean? autoIncrement = false;
> };
>
> IDBIndex   createIndex (in DOMString name, in DOMString keyPath, in optional 
> IDBOptionalParameters optionalParameters) raises (IDBDatabaseException);

We definitely should do this. The reason we didn't originally was that
WebIDL didn't have dictionaries when the current text was written. In
fact, one of the reasons that WebIDL added dictionaries was to allow
IndexedDB to use them :).

The one outstanding issue that I know about is that we want IndexedDB
to throw if any unknown parameters are specified. I don't know if
WebIDL dictionaries support those yet. Or if it's something that we
can specify in prose.

/ Jonas

Re: Request for feedback: DOMCrypt API proposal - random number generation

[Yaron Sheffer]

  
  
Sure, that would be much more efficient. And I agree with others on
that thread that the API should be non-blocking, non-failing, i.e.
akin to Linux /dev/urandom.

But my more important point was the second API: allow the code to
mix in any available entropy: keypresses, file contents, plain old
time, or externally obtained random bytes (http://www.random.org/). Maybe
this API should be called "updateRandom", because it does NOT
determine the full state of the PRNG, which should never be exposed.
I would say this could be an optional API (on Linux it simply
amounts to writing bytes *into* /dev/random, but I don't know if
it's implementable on Windows).

Thanks,
    Yaron

On 06/06/2011 09:44 PM, Aryeh Gregor wrote:

  On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer  wrote:

  
However, I would like to propose one additional feature: a cryptographically
secure random number generator (CSRNG). This is a badly missed feature
today. [And just as I'm posting, I now see that Rich Tibbett beat me to this
idea.]

Specifically I would propose (and I know the details can be debated
forever):

random(): returns a cryptographically-strong 32-bit random integer.
setRandom(r): mixes a user-supplied random integer r into the RNG internal
state.

  
  
This was discussed in February on whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030241.html

I didn't reread the whole thread, but my recollection is that people
preferred an API where you'd give it an ArrayBuffer and it would fill
it with random bytes.  That way you can efficiently get large amounts
of randomness.


  

Re: WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

[Cameron McCormack]

Web Applications Working Group Issue Tracker:
> FileError [1] and FileException [2] both define a DOMString attribute
> called name that contains the name of the error/exception constant as
> a string. Since this is not a useful "human readable" error message,
> and developers should be encouraged to write code that compares
> against the code attribute, it's not clear what the purpose of 'name'
> is. We'd prefer to remove it.

Web IDL specifies that exceptions in ECMAScript will have a name
property on their prototype whose value is the identifier of the
interface.  If name is removed from FileException (and
OperationNotAllowedException, which I also would recommend), then you
will have `aFileException.name == "FileException"`.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [indexeddb] Default direction of Cursors

[Jonas Sicking]

On Mon, Jun 6, 2011 at 10:20 AM, Israel Hilerio  wrote:
> What about this:
>
> The default value for the range will be null which implies:
> IDBKeyRange.lower = undefined
> IDBKeyRange.upper = undefined
> IDBKeyRange.lowerOpen = false
> IDBKeyRange.upperOpen = false

Well, currently the cursor navigation spec text deals with null
cursors rather than cursors such as the above one (which I think can't
be constructed using our current API). So I'm concerned that that
would introduce inconsistencies in the spec.

But as long as you verify that the above text works both together with
the text in the cursor navigation algorithm, as well the definition
for being in a range, then I'm fine with the above.

But I think it would be easier to just say that the default value for
the range argument is null.

/ Jonas

RE: Publishing an update of File API spec

[Adrian Bateman]

On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote:
> Hi Arun, Jonas, All,
>
> The last publication of the File API spec [ED] was last October so it 
> would be good to publish a new Working Draft in w3.org/TR/.
>
> Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not 
> appear to identify any open issues, does the spec meet the Last Call 
> Working Draft requirements (as, indicated in previous CfCs for LCWD such 
> as [CfC-LCWD])?
>
> If not, what is the schedule and plan to get this spec "LC ready"?

I've added two new issues to tracker [1,2] based on our review of the
latest changes to the spec. I think we're getting close to Last Call and
it would be good to set a "pre-Last Call" schedule to tease out any
remaining issues.

Cheers,

Adrian.

[1] http://www.w3.org/2008/webapps/track/issues/181
[2] http://www.w3.org/2008/webapps/track/issues/182

WebApps-ISSUE-182 (OperationNotAllowed): File API introduces a new OperationNotAllowed exception where other specs have an error code [File API]

[Web Applications Working Group Issue Tracker]

WebApps-ISSUE-182 (OperationNotAllowed): File API introduces a new 
OperationNotAllowed exception where other specs have an error code [File API]

http://www.w3.org/2008/webapps/track/issues/182

Raised by: Adrian Bateman
On product: File API

The File API adds an OperationNotAllowed exception with a single 
NOT_ALLOWED_ERR code. [1] Other specs, such as IndexedDB, include 
NOT_ALLOWED_ERR as one code within their existing exception object. [2]

We'd prefer to avoid the overhead of creating a new type just for this error 
and instead add NOT_ALLOWED_ERR as a new code to the existing object in the 
spec.

[1] http://dev.w3.org/2006/webapi/FileAPI/#not-allowed-error
[2] 
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabaseException-NOT_ALLOWED_ERR

WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException name attribute [File API]

[Web Applications Working Group Issue Tracker]

WebApps-ISSUE-181 (FileError-Name): Use case for FileError and FileException 
name attribute [File API]

http://www.w3.org/2008/webapps/track/issues/181

Raised by: Adrian Bateman
On product: File API

FileError [1] and FileException [2] both define a DOMString attribute called 
name that contains the name of the error/exception constant as a string. Since 
this is not a useful "human readable" error message, and developers should be 
encouraged to write code that compares against the code attribute, it's not 
clear what the purpose of 'name' is. We'd prefer to remove it.

[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-nameError
[2] http://dev.w3.org/2006/webapi/FileAPI/#dfn-name-exception

Re: [indexeddb] Section 4.1 - Opening the database (error codes)

[Jeremy Orlow]

Unknown err might make sense for implementation specific bugs/issues.  (If
it's not deeply tied to an implementation, it shouldn't be "unknown"
though.)

On Mon, Jun 6, 2011 at 9:43 AM, Jonas Sicking  wrote:

> On Mon, Jun 6, 2011 at 9:29 AM, Israel Hilerio 
> wrote:
> > The first step in section 4.1 "Opening the database" stipulates:
> >
> > 1. If these steps fail for any reason, return a error with the
> appropriate code and abort this algorithm.
> >
> > What are the expected error codes for IDBFactory.open?
>
> I think it's mostly QUOTA_ERR that makes sense there.
>
> / Jonas
>
>

[indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

[Israel Hilerio]

Have you considered using the WebIDL dictionary definition as a mechanism to 
define the optional parameters in the IDBDatabase.createObjectStore method?

Advantages at using the dictionary definition on WebIDL for optional parameters:
. Provides a fixed, ordered set of key-value pairs
. Removes the need to walk the hierarchy chain to determine if these attributes 
are available
. Provides default values for each of its key-value pairs
. Enables an extensible pattern to add new capabilities in the future

I believe this will change our current method definition to the following:

dictionary IDBOptionalParameters {
   DOMString? keyPath = null;
   boolean? autoIncrement = false;
};

IDBIndex   createIndex (in DOMString name, in DOMString keyPath, in optional 
IDBOptionalParameters optionalParameters) raises (IDBDatabaseException);

Israel

Re: Request for feedback: DOMCrypt API proposal - random number generation

[Aryeh Gregor]

On Sat, Jun 4, 2011 at 1:52 AM, Yaron Sheffer  wrote:
> However, I would like to propose one additional feature: a cryptographically
> secure random number generator (CSRNG). This is a badly missed feature
> today. [And just as I'm posting, I now see that Rich Tibbett beat me to this
> idea.]
>
> Specifically I would propose (and I know the details can be debated
> forever):
>
> random(): returns a cryptographically-strong 32-bit random integer.
> setRandom(r): mixes a user-supplied random integer r into the RNG internal
> state.

This was discussed in February on whatwg:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030241.html

I didn't reread the whole thread, but my recollection is that people
preferred an API where you'd give it an ArrayBuffer and it would fill
it with random bytes.  That way you can efficiently get large amounts
of randomness.

RE: [indexeddb] Default direction of Cursors

[Israel Hilerio]

What about this:

The default value for the range will be null which implies:
IDBKeyRange.lower = undefined
IDBKeyRange.upper = undefined
IDBKeyRange.lowerOpen = false
IDBKeyRange.upperOpen = false

The default value for the direction will be IDBCursor.NEXT.

Israel

On Mon, Jun 6, 2011 at 10:03 AM, Jonas Sicking wrote:
> On Mon, Jun 6, 2011 at 9:47 AM, Israel Hilerio 
> wrote:
> > On Mon, May 23, 2011 at 4:30 PM, Jonas Sicking wrote:
> >> On Mon, May 23, 2011 at 12:54 PM, Israel Hilerio
> >> 
> >> wrote:
> >> > I noticed that we don't define the default direction of a cursor
> >> > when
> >> accessing records.  Both, Firefox and Chrome go from smallest to
> >> largest.  This seems reasonable to us.  Can we record this behavior
> >> on the spec?
> >>
> >> Wow, good catch, that's a pretty glaring hole indeed. Yes, all
> >> cursors should default to NEXT as direction IMHO.
> >>
> >> / Jonas
> >
> > How about adding the following to section "3.1.10 Cursor" to define the
> default behavior:
> >
> > "The default direction of a cursor is to move in a monolithically
> > increasing order of the record keys.  The default range of a cursor is
> > unbounded (that is, it has no upper and lower bounds defined). It is
> > also closed, which implies it includes the endpoints."
> 
> Just specify the actual values that should be used as defaults instead. I.e.
> IDBCursor.NEXT for the direction and null for the range.
> That way the algorithms actually iterating the cursor will fully define all 
> edge
> cases. Your above text makes it unclear for example what happens if the
> backing store is modified during iteration.
> 
> / Jonas

Re: [indexeddb] Default direction of Cursors

[Jonas Sicking]

On Mon, Jun 6, 2011 at 9:47 AM, Israel Hilerio  wrote:
> On Mon, May 23, 2011 at 4:30 PM, Jonas Sicking wrote:
>> On Mon, May 23, 2011 at 12:54 PM, Israel Hilerio 
>> wrote:
>> > I noticed that we don't define the default direction of a cursor when
>> accessing records.  Both, Firefox and Chrome go from smallest to
>> largest.  This seems reasonable to us.  Can we record this behavior on the
>> spec?
>>
>> Wow, good catch, that's a pretty glaring hole indeed. Yes, all cursors should
>> default to NEXT as direction IMHO.
>>
>> / Jonas
>
> How about adding the following to section "3.1.10 Cursor" to define the 
> default behavior:
>
> "The default direction of a cursor is to move in a monolithically
> increasing order of the record keys.  The default range of a cursor is
> unbounded (that is, it has no upper and lower bounds defined). It is
> also closed, which implies it includes the endpoints."

Just specify the actual values that should be used as defaults
instead. I.e. IDBCursor.NEXT for the direction and null for the range.
That way the algorithms actually iterating the cursor will fully
define all edge cases. Your above text makes it unclear for example
what happens if the backing store is modified during iteration.

/ Jonas

RE: [indexeddb] Default direction of Cursors

[Israel Hilerio]

On Mon, May 23, 2011 at 4:30 PM, Jonas Sicking wrote:
> On Mon, May 23, 2011 at 12:54 PM, Israel Hilerio 
> wrote:
> > I noticed that we don't define the default direction of a cursor when
> accessing records.  Both, Firefox and Chrome go from smallest to
> largest.  This seems reasonable to us.  Can we record this behavior on the
> spec?
> 
> Wow, good catch, that's a pretty glaring hole indeed. Yes, all cursors should
> default to NEXT as direction IMHO.
> 
> / Jonas

How about adding the following to section "3.1.10 Cursor" to define the default 
behavior:

"The default direction of a cursor is to move in a monolithically 
increasing order of the record keys.  The default range of a cursor is 
unbounded (that is, it has no upper and lower bounds defined). It is 
also closed, which implies it includes the endpoints."

Israel

Re: [indexeddb] Section 4.1 - Opening the database (error codes)

[Jonas Sicking]

On Mon, Jun 6, 2011 at 9:29 AM, Israel Hilerio  wrote:
> The first step in section 4.1 "Opening the database" stipulates:
>
> 1. If these steps fail for any reason, return a error with the appropriate 
> code and abort this algorithm.
>
> What are the expected error codes for IDBFactory.open?

I think it's mostly QUOTA_ERR that makes sense there.

/ Jonas

[indexeddb] Section 4.1 - Opening the database (error codes)

[Israel Hilerio]

The first step in section 4.1 "Opening the database" stipulates:

1. If these steps fail for any reason, return a error with the appropriate code 
and abort this algorithm.

What are the expected error codes for IDBFactory.open?

Israel

Re: Publishing an update of File API spec

[Dominique Hazael-Massieux]

Le lundi 06 juin 2011 à 08:55 -0400, Arthur Barstow a écrit :
> The last publication of the File API spec [ED] was last October so it 
> would be good to publish a new Working Draft in w3.org/TR/.
> 
> Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not 
> appear to identify any open issues, does the spec meet the Last Call 
> Working Draft requirements (as, indicated in previous CfCs for LCWD such 
> as [CfC-LCWD])?

Note that the Web IDL fragments in that document are not valid:
http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org%
2F2006%2Fwebapi%2FFileAPI%2F&input=&output=html

I would fix them myself, but last time I did it, that created troubles
for the editor; I think the fixes are likely the same as the ones that
were reverted back then:
http://dev.w3.org/cvsweb/2006/webapi/FileAPI/Overview.html.diff?r1=1.55;r2=1.57;f=h

Dom

Publishing an update of File API spec

[Arthur Barstow]

Hi Arun, Jonas, All,

The last publication of the File API spec [ED] was last October so it 
would be good to publish a new Working Draft in w3.org/TR/.


Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not 
appear to identify any open issues, does the spec meet the Last Call 
Working Draft requirements (as, indicated in previous CfCs for LCWD such 
as [CfC-LCWD])?


If not, what is the schedule and plan to get this spec "LC ready"?

In case people missed it, Arun started a discussion about the blob URI 
scheme on the URI mail list:


  http://lists.w3.org/Archives/Public/uri/2011May/.html

-Thanks, AB

[ED] http://dev.w3.org/2006/webapi/FileAPI/
[Tracker] http://www.w3.org/2008/webapps/track/products/19
[CfC-LCWD] 
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0546.html

Re: Status of URL Interface?

[Arthur Barstow]

Given the positive support indicated, one way forward with respect to 
WebApps is for Adam to put his spec into WebApps' Mercurial repo and to 
continue related discussions on public-webapps.


Note, WebApps cannot publish this spec (in w3.org/TR/) until the spec is 
included in the WG's charter. Our current charter does not expire until 
June 2012 and at this point in time, I would not support re-chartering 
just for this one spec. (I am not aware of any urgency to publish this 
spec so if I missed something, please speak up.)


If anyone has any comments or concerns about proceeding as above, please 
send you comments to public-webapps.


-Art Barstow

On Jun/2/2011 2:37 PM, ext Ian Hickson wrote:

On Thu, 2 Jun 2011, Arun Ranganathan wrote:

On 6/1/11 5:42 PM, Adam Barth wrote:

I've been implementing bits and pieces in WebKit.  If there's interest
from other implementors, I'm happy to work on the document in the W3C
process.

I'm definitely interested in seeing this become a rec-track document.  Ad-hoc
pieces of this live in other specs.  For instance, both WHATWG Stream API and
FileAPI reference URL.createObjectURL(blob) as defined here:

http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking

I'd like to see this interface live somewhere more formal than its
present incarnation as a Google Doc.

Hear hear. I'm also interested in Adam's work on URL parsing and
resolution; currently the HTML spec has some outdated text on this but it
would be great for it to be fixed. I don't mind where this lives though
(as an independent spec or in one of the existing specs).

Re: Battery Status API vs. Geolocation API

[Arthur Barstow]

[ Bcc public-webapps; please reply to public-device-a...@w3.org ]

As noted in the Battery Status Event spec, comments for the spec should 
be sent to the DAP WG's mail list:


public-device-a...@w3.org 

On Jun/6/2011 1:44 AM, ext Andres Riofrio wrote:

Hello,

I have some comments on the Battery Status API.

I was wondering why it was that the battery status API is exposed
using Events (and adding an additional requirement "When an event
listener is registered with the event type batterystatus, then the
User Agent must dispatch a BatteryStatusEvent event immediately."),
when the Geolocation API is exposed using a getCurrent and a watch
function, that invoke a callback when the information is available. Is
there a rationale for using a different paradigm than the (kind of)
established Geolocation API? I think it'd be better (saner for
developers) to use the same paradigm.

Further, doesn't the requirement that a BatteryStatusEvent be
dispatched immediately incur a synchronous delay as the browser gets
that information? That is, nothing else can happen because the event
must be dispatched immediately. I might understand wrongly, but if
this is the case, I think it should be changed to "retrieves the
relevant information and dispatches a BatteryStatusEvent
asynchronously".

Andres Riofrio

Re: Battery Status API vs. Geolocation API

[Dominique Hazael-Massieux]

Hello Andres,

The Battery Status API is deliverable of the Device APIs Working Group,
so I'm copying the group's list public-device-a...@w3.org.

(keeping public-webapps in BCC FYI)

Dom

Le dimanche 05 juin 2011 à 22:44 -0700, Andres Riofrio a écrit :
> I have some comments on the Battery Status API.
> 
> I was wondering why it was that the battery status API is exposed
> using Events (and adding an additional requirement "When an event
> listener is registered with the event type batterystatus, then the
> User Agent must dispatch a BatteryStatusEvent event immediately."),
> when the Geolocation API is exposed using a getCurrent and a watch
> function, that invoke a callback when the information is available. Is
> there a rationale for using a different paradigm than the (kind of)
> established Geolocation API? I think it'd be better (saner for
> developers) to use the same paradigm.
> 
> Further, doesn't the requirement that a BatteryStatusEvent be
> dispatched immediately incur a synchronous delay as the browser gets
> that information? That is, nothing else can happen because the event
> must be dispatched immediately. I might understand wrongly, but if
> this is the case, I think it should be changed to "retrieves the
> relevant information and dispatches a BatteryStatusEvent
> asynchronously".
> 
> Andres Riofrio
> 
> 
> 

Battery Status API vs. Geolocation API

[Andres Riofrio]

Hello,

I have some comments on the Battery Status API.

I was wondering why it was that the battery status API is exposed
using Events (and adding an additional requirement "When an event
listener is registered with the event type batterystatus, then the
User Agent must dispatch a BatteryStatusEvent event immediately."),
when the Geolocation API is exposed using a getCurrent and a watch
function, that invoke a callback when the information is available. Is
there a rationale for using a different paradigm than the (kind of)
established Geolocation API? I think it'd be better (saner for
developers) to use the same paradigm.

Further, doesn't the requirement that a BatteryStatusEvent be
dispatched immediately incur a synchronous delay as the browser gets
that information? That is, nothing else can happen because the event
must be dispatched immediately. I might understand wrongly, but if
this is the case, I think it should be changed to "retrieves the
relevant information and dispatches a BatteryStatusEvent
asynchronously".

Andres Riofrio