On Fri, Dec 10, 2010 at 3:30 PM, Eric Uhrhane wrote:
> On Fri, Dec 10, 2010 at 3:17 PM, James Robinson wrote:
>> On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote:
>>>
>>> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren
>>> wrote:
>>> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jeremy Orlow
Sent: Friday, December 10, 2010 7:27 AM
>>
>> In addition to createObjectStore, I also intend to convert the following
>> over:
>>
>>
>> IDBObjectStore.createIndex
>> IDBObjectStore.openCursor
>
On Fri, Dec 10, 2010 at 3:17 PM, James Robinson wrote:
> On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote:
>>
>> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren
>> wrote:
>> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
>> > Tracker wrote:
>> >>
>> >> ISSUE-17
On Fri, Dec 10, 2010 at 2:04 PM, Eric Uhrhane wrote:
> On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren
> wrote:
> > On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
> > Tracker > wrote:
> >>
> >> ISSUE-173 (ericu): terminal FileWriter progress events should be queued
>
Jonas Sicking:
> Specifying an exception to throw for functions that take enums if a
> invalid value is passed to the function.
Ah, I misunderstood. Would you want a standard exception (like
TypeError, or one of the DOMExceptions from DOM Core) or be able to
have the IDL specify what exception is
On Fri, Dec 10, 2010 at 1:57 PM, Cameron McCormack wrote:
> Jeremy Orlow:
>> > Similar with the direction for openCursor or anything that takes in
>> > an enum. I don't see any existing error that's a particularly good
>> > match for these. Maybe I should add an ENUM_ERR or something?
>
> Jonas Si
On Fri, Dec 10, 2010 at 2:39 AM, Anne van Kesteren wrote:
> On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
> Tracker wrote:
>>
>> ISSUE-173 (ericu): terminal FileWriter progress events should be queued
>> [File API: Writer]
>>
>> http://www.w3.org/2008/webapps/track/issu
Jeremy Orlow:
> > Similar with the direction for openCursor or anything that takes in
> > an enum. I don't see any existing error that's a particularly good
> > match for these. Maybe I should add an ENUM_ERR or something?
Jonas Sicking:
> Would be great if WebIDL could help out here. Cameron, I s
On Fri, Dec 10, 2010 at 7:49 AM, Jeremy Orlow wrote:
> Similar with the direction for openCursor or anything that takes in an enum.
> I don't see any existing error that's a particularly good match for these.
> Maybe I should add an ENUM_ERR or something?
Would be great if WebIDL could help out h
On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow wrote:
> Any more thoughts on this?
I don't feel strongly one way or another. Implementation wise I don't
really understand why implementations couldn't use keys of unlimited
size. I wouldn't imagine implementations would want to use fixed-size
alloca
On Fri, Dec 10, 2010 at 6:48 AM, Jeremy Orlow wrote:
> What exception should we throw? CONSTRAINT_ERR?
Sounds good to me.
/ Jonas
I've been reaching out to get feedback, but no success yet. Will re-poke.
/ Jonas
On Fri, Dec 10, 2010 at 4:33 AM, Jeremy Orlow wrote:
> Any additional thoughts on this? If no one else cares, then we can go with
> Jonas' proposal (and we should file a bug).
> J
>
> On Thu, Nov 11, 2010 at 12:06
On Fri, Dec 10, 2010 at 6:01 PM, Shawn Wilsher wrote:
> On 12/10/2010 5:03 AM, Jeremy Orlow wrote:
>
>> Speaking of which, we use UNKNOWN_ERR for a bunch of other
>> internal consistency issues. Is this OK by everyone, should we use
>> another,
>> or should we create a new one? (Ideally these i
On 12/10/2010 7:27 AM, Jeremy Orlow wrote:
We did all of these two weeks ago in Chromium and have gotten some feedback.
The main downside is that typos are silently ignored by JavaScript. We
considered throwing if someone passed in an option we didn't recognize, but
this would make it impossib
On 12/10/2010 5:03 AM, Jeremy Orlow wrote:
Speaking of which, we use UNKNOWN_ERR for a bunch of other
internal consistency issues. Is this OK by everyone, should we use another,
or should we create a new one? (Ideally these issues will be few and far
between as we make things more robust.)
Wou
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11530
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11530
Summary: No transaction should start until after all others
that were created first and whose scope overlaps
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: A
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11527
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11528
Summary: We should add some form of dynamic transaction to
IndexedDB
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Sev
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11527
Summary: Remove dynamic transactions from the spec
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Similar with the direction for openCursor or anything that takes in an enum.
I don't see any existing error that's a particularly good match for these.
Maybe I should add an ENUM_ERR or something?
J
On Thu, Nov 25, 2010 at 12:42 PM, wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11406
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11349
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Any more thoughts on this?
On Mon, Nov 22, 2010 at 12:05 PM, Jeremy Orlow wrote:
> Something working (but with degraded performance) is better than not
> working at all. Especially when keys will often come from user data/input
> and thus simple web apps will likely not handle the exceptions la
In addition to createObjectStore, I also intend to convert the following over:
IDBObjectStore.createIndex
IDBObjectStore.openCursor
IDBIndex.openCursor
IDBIndex.openKeyCursor
IDBKeyRange.bound
We did all of these two weeks ago in Chromium and have gotten some feedback.
The main downside is that
What exception should we throw? CONSTRAINT_ERR?
On Tue, Nov 23, 2010 at 11:50 PM, wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11394
>
> Summary: We should throw if continue() is called with a key <=
>the current position
> Product: WebAppsWG
>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11389
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
I was confused re not overlapping with other exception codes. As long as we
don't have overlap within this particular exception type, we're OK.
I noticed that QUOTA_ERR is commented out. I can't remember when or why and
the blame history is a bit mangled. Does anyone else? In Chromium we
curre
Any other thoughts on this issue?
On Thu, Dec 2, 2010 at 7:19 AM, Keean Schupke wrote:
> I think I prefer A. Declaring the keys in advance is stating to sound a
> little like a schema, and when you go down that route you end up at SQL
> schemas (which is a good thing in my opinion). I understand
Any additional thoughts on this? If no one else cares, then we can go with
Jonas' proposal (and we should file a bug).
J
On Thu, Nov 11, 2010 at 12:06 PM, Jeremy Orlow wrote:
> On Tue, Nov 9, 2010 at 11:35 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> One of the things we briefly discussed at t
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9769
Jeremy Orlow changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10303
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10590
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11407
Jeremy Orlow changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, 10 Dec 2010 03:24:38 +0100, Web Applications Working Group Issue
Tracker wrote:
ISSUE-173 (ericu): terminal FileWriter progress events should be queued
[File API: Writer]
http://www.w3.org/2008/webapps/track/issues/173
Raised by: Eric Uhrhane
On product: File API: Writer
When a Fil
34 matches
Mail list logo
