Re: [IndexedDB] Numeric constants vs enumerated strings

[Jonas Sicking]

Oh, but I should add that I think it's fine for implementations to
keep support for the numbers for a transition period if they so
desire.

/ Jonas

On Thu, Feb 23, 2012 at 1:27 AM, Jonas Sicking  wrote:
> Yes! I would love to make this change.
>
> This is my main peeve with the API as it stands.
>
> I even think that implementations could remove support for the numbers
> by keeping the constants but have them defined to return string
> values. I.e.
>
> db.transaction(["store"], IDBTransaction.READ_WRITE);
>
> would continue to work and is the usage pattern that I've seen in all
> code that I've looked at.
>
> Yes, the read-only attributes would change, but like Joshua I've never
> seen code use those so far.
>
> / Jonas
>
> On Wed, Feb 22, 2012 at 6:02 PM, Joshua Bell  wrote:
>> On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal  wrote:
>>>
>>> I propose that we change the numeric constants to enumerated strings in
>>> the IndexedDB spec.
>>>
>>> Reasoning is echoing the reasoning that came up for WebRTC:
>>>
>>> 
>>
>> ...
>>>
>>>
>>> So. What do you think? :-)
>>
>>
>> I don't have strong feelings about this proposal either way. Ignoring the
>> *Sync APIs, this would involve changing:
>>
>> Methods:
>> IDBDatabase.transaction() - mode
>> IDBObjectStore.openCursor() - direction
>> IDBIndex.openCursor() - direction
>> IDBIndex.openKeyCursor() - direction
>>
>> Attributes (read-only):
>> IDBRequest.readyState
>> IDBCursor.direction
>> IDBTransaction.mode
>>
>> During a transition period, implementations of the methods could take either
>> a number or a string. The attributes are not so easy; it would be a breaking
>> change. Fortunately, those attributes are generally informative rather than
>> critical for app logic (at least, in the code I've seen), so the impact is
>> likely to be low. JS authors could check for both values (e.g.
>> request.readyState === IDBRequest.DONE || request.readyState === "done"),
>> just as authors must work around implementation differences today. So IMHO
>> it's plausible to make this change with little impact.
>>

Re: [IndexedDB] Numeric constants vs enumerated strings

[Jonas Sicking]

Yes! I would love to make this change.

This is my main peeve with the API as it stands.

I even think that implementations could remove support for the numbers
by keeping the constants but have them defined to return string
values. I.e.

db.transaction(["store"], IDBTransaction.READ_WRITE);

would continue to work and is the usage pattern that I've seen in all
code that I've looked at.

Yes, the read-only attributes would change, but like Joshua I've never
seen code use those so far.

/ Jonas

On Wed, Feb 22, 2012 at 6:02 PM, Joshua Bell  wrote:
> On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal  wrote:
>>
>> I propose that we change the numeric constants to enumerated strings in
>> the IndexedDB spec.
>>
>> Reasoning is echoing the reasoning that came up for WebRTC:
>>
>> 
>
> ...
>>
>>
>> So. What do you think? :-)
>
>
> I don't have strong feelings about this proposal either way. Ignoring the
> *Sync APIs, this would involve changing:
>
> Methods:
> IDBDatabase.transaction() - mode
> IDBObjectStore.openCursor() - direction
> IDBIndex.openCursor() - direction
> IDBIndex.openKeyCursor() - direction
>
> Attributes (read-only):
> IDBRequest.readyState
> IDBCursor.direction
> IDBTransaction.mode
>
> During a transition period, implementations of the methods could take either
> a number or a string. The attributes are not so easy; it would be a breaking
> change. Fortunately, those attributes are generally informative rather than
> critical for app logic (at least, in the code I've seen), so the impact is
> likely to be low. JS authors could check for both values (e.g.
> request.readyState === IDBRequest.DONE || request.readyState === "done"),
> just as authors must work around implementation differences today. So IMHO
> it's plausible to make this change with little impact.
>

Re: [DOM4] Constructor for DOMException?

[Cameron McCormack]

João Eiras:

DOMExceptions have both a code and a message. Perhaps the
constructor should be extended to include both.


Anne van Kesteren:

code is legacy, but name would be good to expose.


The constructor has the same signature as the standard ECMAScript Error 
constructors, so we are being consistent there.  I think it's fine for 
code and name to be assigned after creating the object, if JS needs to 
create a DOMException object (which I don't expect to be a common thing 
anyway).

RE: StreamBuilder threshold

[Feras Moussa]

> -Original Message-
> From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com]
> Sent: Sunday, February 05, 2012 4:50 AM
> To: Feras Moussa
> Cc: Travis Leithead; public-webapps@w3.org
> Subject: Re: StreamBuilder threshold
> 
> On 01/26/2012 07:05 PM, Feras Moussa wrote:
> > Can you please clarify what scenario you are looking at regarding
> > multiple consumers? When designing the StreamBuilder API, we looked at
> > it as a more primitive API which other abstractions (such as multiple
> > consumers) can be built upon.
> 
> (Please forgive me if I am making stupid input - I am in a learning phase). A
> very simple scenario would be the example in the draft that "demonstrates
> how to use StreamBuilder to load a stream into the audio tag". In this
> example the consumer is an audio tag, and new data is appended to the
> stream each time the buffer falls below 1024 bytes. Fine so far, but what
> happens if the same stream (via createObjectURL) is connected to one more
> audio tag, but at T ms later.
> 
> In this case the first audio tag would have consumed down to the threshold
> (1024 bytes) T ms before the second.

This isn't clear from the spec (And I've made a note to clarify it) but URLs for
 streams should be one time use URLs (once used it should be automatically 
revoked). Thus a scenario as you said below (connecting the same stream to 
multiple tags) isn't possible. There will only be one event to notify the 
threshold 
has been reached, thus there should not be multiple consumers 'racing' for this 
event.
 
> Another example could be that one Stream is uploaded using two parallel
> xhr's; one of them could have a couple of pakcet losses and then consume
> slower than the other (and if WS could take send(stream) the same would
> apply).
> >
> > If you can please let me know what issue you're trying to address, I'm
> > happy to discuss the possibilities.
> 
> I hope the above input explained the issue.

However, I'm still not clear on what the scenario you'd like to accomplish is - 
can 
you please explain it in more detail? If you're looking for a way to reuse data 
from a Stream, then you should use StreamReader to read the data as a Blob 
(or another type) which will then provide you with all the Blob semantics, 
including multiple reads on the data.

Thanks,
Feras

 
> >
> > Also, For future reference, the latest draft is now located on the W3
> > site at http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
> 
> Thanks for updating me!
> 
> Stefan
> 
> >
> > Thanks, Feras
> >
> >> -Original Message- From: Stefan Hakansson LK
> >> [mailto:stefan.lk.hakans...@ericsson.com] Sent: Tuesday, January 17,
> >> 2012 12:28 AM To: Feras Moussa; Travis Leithead Cc:
> >> public-webapps@w3.org Subject: StreamBuilder threshold
> >>
> >> I'm looking at
> >> http://html5labs.interoperabilitybridges.com/streamsapi/, and
> >> specifically at the StreamBuilder.
> >>
> >> It has the possibility to generate an event if the data available
> >> falls below a threshold. How is this supposed to work if there is
> >> more than one consumer, and those consumers either don't start
> >> consuming at exactly the same time or consume at different rates, of
> >> the Stream?
> >>
> >> --Stefan
> >
> >
> 

[Bug 14408] [IndexedDB] Cursors .key/.primaryKey/.value shouldn't throw as soon as .continue is called

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14408

Israel Hilerio [MSFT]  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Israel Hilerio [MSFT]  2012-02-22 
18:16:28 UTC ---
Jonas, Thanks for the feedback.  This makese sense. I'll go ahead and close the
bug.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [IndexedDB] Numeric constants vs enumerated strings

[Joshua Bell]

On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal  wrote:

> I propose that we change the numeric constants to enumerated strings in
> the IndexedDB spec.
>
> Reasoning is echoing the reasoning that came up for WebRTC:
>  2012JanMar/0166.html
> >
>
...

>
> So. What do you think? :-)


I don't have strong feelings about this proposal either way. Ignoring the
*Sync APIs, this would involve changing:

Methods:
IDBDatabase.transaction() - mode
IDBObjectStore.openCursor() - direction
IDBIndex.openCursor() - direction
IDBIndex.openKeyCursor() - direction

Attributes (read-only):
IDBRequest.readyState
IDBCursor.direction
IDBTransaction.mode

During a transition period, implementations of the methods could take
either a number or a string. The attributes are not so easy; it would be a
breaking change. Fortunately, those attributes are generally informative
rather than critical for app logic (at least, in the code I've seen), so
the impact is likely to be low. JS authors could check for both values
(e.g. request.readyState === IDBRequest.DONE || request.readyState ===
"done"), just as authors must work around implementation differences today.
So IMHO it's plausible to make this change with little impact.

Re: [DOM4] Constructor for DOMException?

[Anne van Kesteren]

On Wed, 22 Feb 2012 15:27:41 +0100, João Eiras  wrote:
On Wed, 22 Feb 2012 00:00:24 +0100, Cameron McCormack   
wrote:
Web IDL already requires exception interface objects like DOMException  
to be constructable, due to this:


   http://dev.w3.org/2006/webapi/WebIDL/#es-exception-call

and them being Function objects.  The constructor should take a single  
argument which is the message.


DOMExceptions have both a code and a message. Perhaps the constructor  
should be extended to include both.


code is legacy, but name would be good to expose.


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

Re: [DOM4] Constructor for DOMException?

[João Eiras]

On Wed, 22 Feb 2012 00:00:24 +0100, Cameron McCormack   
wrote:



Marcos Caceres:

So… given that one can fake create a DOMException, and unless there
is a valid reason not to allow this that I don't know of…. It would
be nice if DOMException just defined a public constructor. This would
allow clean prototyping of various APIs in ECMAScript (and give us
poor saps who don't know C a chance to implement some Web APIs :) ).


Web IDL already requires exception interface objects like DOMException  
to be constructable, due to this:


   http://dev.w3.org/2006/webapi/WebIDL/#es-exception-call

and them being Function objects.  The constructor should take a single  
argument which is the message.


DOMExceptions have both a code and a message. Perhaps the constructor  
should be extended to include both.

[IndexedDB] Numeric constants vs enumerated strings

[Odin Hørthe Omdal]

I propose that we change the numeric constants to enumerated strings in  
the IndexedDB spec.


Reasoning is echoing the reasoning that came up for WebRTC:


I'll just shamelessy quote Tobie Langel  
:



Anne van Kesteren saying:
Unless there are strong ties to certain legacy APIs I would suggest  
using

strings. They are easier for developers to author, easier for developers
to maintain, easier in the future to extend, and have practically no
drawbacks.



I second that. Authors barely ever used the defined constants (for good
reason, some implementations were missing them) preferring to use  
integers

directly.

Instead of seeing the verbose but descriptive:

if (node.nodeType == Node.ELEMENT_NODE) { ... }

one came across the following more often than not:

if (node.nodeType == 1) { ... }

to which:
if (node.nodeType ==  "element") { ... }

should be preferred.

Constants would only have practical benefits over strings if they were
defined in the global scope, as in:

if (node.nodeType == NODE_ELEMENT_NODE) { ... }

as typos would be caught early on (undeclared variables throw
ReferenceErrors).



So. What do you think? :-)



--
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /