On Jun 22, 2010, at 12:44 AM, Andrei Popescu wrote:
> On Tue, Jun 15, 2010 at 5:44 PM, Nikunj Mehta wrote:
>> (specifically answering out of context)
>>
>> On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
>>
>>> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
>>> We cou
On Tue, Jun 15, 2010 at 5:44 PM, Nikunj Mehta wrote:
> (specifically answering out of context)
>
> On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
>
>> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
>> We couldn't figure out how the old API allowed you to create a range
>
On Tue, Jun 15, 2010 at 9:44 AM, Nikunj Mehta wrote:
> (specifically answering out of context)
>
> On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
>
>> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
>> We couldn't figure out how the old API allowed you to create a range
>
(specifically answering out of context)
On May 17, 2010, at 6:15 PM, Jonas Sicking wrote:
> 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest.
> We couldn't figure out how the old API allowed you to create a range
> object without first having a range object.
Hey Jonas,
What
On Thu, Jun 10, 2010 at 11:17 AM, Andrei Popescu wrote:
> On Thu, Jun 10, 2010 at 5:52 PM, Jonas Sicking wrote:
>> On Thu, Jun 10, 2010 at 4:46 AM, Andrei Popescu wrote:
>>> Hi Jonas,
>>>
>>> On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking wrote:
I'm well aware of this. My argument is
On Thu, Jun 10, 2010 at 5:52 PM, Jonas Sicking wrote:
> On Thu, Jun 10, 2010 at 4:46 AM, Andrei Popescu wrote:
>> Hi Jonas,
>>
>> On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking wrote:
>>>
>>> I'm well aware of this. My argument is that I think we'll see people
>>> write code like this:
>>>
>>> r
On Thu, Jun 10, 2010 at 4:46 AM, Andrei Popescu wrote:
> Hi Jonas,
>
> On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking wrote:
>>
>> I'm well aware of this. My argument is that I think we'll see people
>> write code like this:
>>
>> results = [];
>> db.objectStore("foo").openCursor(range).onsuccess
Hi Jonas,
On Wed, Jun 9, 2010 at 11:27 PM, Jonas Sicking wrote:
>
> I'm well aware of this. My argument is that I think we'll see people
> write code like this:
>
> results = [];
> db.objectStore("foo").openCursor(range).onsuccess = function(e) {
> var cursor = e.result;
> if (!cursor) {
> w
I've been looking through the current spec and all the proposed changes.
Great work. I'm going to be building a CouchDB compatible API on top
of IndexedDB that can support peer-to-peer replication without other
CouchDB instances.
One of the things that will entail is a by-sequence index for all t
On 6/9/2010 3:36 PM, Tab Atkins Jr. wrote:
At the very least, explicitly loading things into an honest-to-god
array can make it more obvious that you're eating memory in the form
of a big array, as opposed to just a "magically transform my blob of
data into something more convenient".
I'm sorry,
On Wed, Jun 9, 2010 at 3:36 PM, Tab Atkins Jr. wrote:
> On Wed, Jun 9, 2010 at 3:27 PM, Jonas Sicking wrote:
>> I'm well aware of this. My argument is that I think we'll see people
>> write code like this:
>>
>> results = [];
>> db.objectStore("foo").openCursor(range).onsuccess = function(e) {
>>
On 6/9/2010 3:48 PM, Kris Zyp wrote:
Another option would be to have cursors essentially implement a JS
array-like API:
db.objectStore("foo").openCursor(range).forEach(function(object){
// do something with each object
}).onsuccess = function(){
// all done
});
(Or perhaps the cursor wit
apps-requ...@w3.org] On Behalf Of Jonas Sicking
>> Sent: Wednesday, June 09, 2010 11:55 PM
>> To: Jeremy Orlow
>> Cc: Shawn Wilsher; Webapps WG
>> Subject: Re: [IndexDB] Proposal for async API changes
>>
>> On Wed, Jun 9, 2010 at 7:42 AM, Jeremy Orlow wrote:
>&
On Wed, Jun 9, 2010 at 11:40 AM, Jeremy Orlow wrote:
> On Wed, Jun 9, 2010 at 7:25 PM, Jonas Sicking wrote:
>>
>> On Wed, Jun 9, 2010 at 7:42 AM, Jeremy Orlow wrote:
>> > On Tue, May 18, 2010 at 8:34 PM, Jonas Sicking wrote:
>> >>
>> >> On Tue, May 18, 2010 at 12:10 PM, Jeremy Orlow
>> >> wrot
On Wed, Jun 9, 2010 at 3:27 PM, Jonas Sicking wrote:
> I'm well aware of this. My argument is that I think we'll see people
> write code like this:
>
> results = [];
> db.objectStore("foo").openCursor(range).onsuccess = function(e) {
> var cursor = e.result;
> if (!cursor) {
> weAreDone(resul
emy Orlow
> Cc: Shawn Wilsher; Webapps WG
> Subject: Re: [IndexDB] Proposal for async API changes
>
> On Wed, Jun 9, 2010 at 7:42 AM, Jeremy Orlow wrote:
>> On Tue, May 18, 2010 at 8:34 PM, Jonas Sicking wrote:
>>>
>>> On Tue, May 18, 2010 at 12:10 PM, Jeremy Orlow
On Wed, Jun 9, 2010 at 7:25 PM, Jonas Sicking wrote:
> On Wed, Jun 9, 2010 at 7:42 AM, Jeremy Orlow wrote:
> > On Tue, May 18, 2010 at 8:34 PM, Jonas Sicking wrote:
> >>
> >> On Tue, May 18, 2010 at 12:10 PM, Jeremy Orlow
> >> wrote:
> >> > I'm not sure I like the idea of offering sync cursors
Inline...
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jonas Sicking
Sent: Wednesday, June 09, 2010 11:55 PM
To: Jeremy Orlow
Cc: Shawn Wilsher; Webapps WG
Subject: Re: [IndexDB] Proposal for async API changes
On Wed, Jun 9
On Wed, Jun 9, 2010 at 7:42 AM, Jeremy Orlow wrote:
> On Tue, May 18, 2010 at 8:34 PM, Jonas Sicking wrote:
>>
>> On Tue, May 18, 2010 at 12:10 PM, Jeremy Orlow
>> wrote:
>> > I'm not sure I like the idea of offering sync cursors either since the
>> > UA
>> > will either need to load everything
On Tue, May 18, 2010 at 8:34 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 12:10 PM, Jeremy Orlow
> wrote:
> > I'm not sure I like the idea of offering sync cursors either since the UA
> > will either need to load everything into memory before starting or risk
> > blocking on disk IO for la
Hi Jonas,
>
>> A draft of the proposed API is here:
>
> http://docs.google.com/View?id=dfs2skx2_4g3s5f857
>
As someone new to this API, I thought the naming used in the current
draft is somewhat confusing. Consider the following interfaces:
IndexedDatabase
IndexedDatabaseRequest,
IDBDatabaseRequ
On Tue, May 18, 2010 at 2:15 AM, Jonas Sicking wrote:
> A draft of the proposed API is here:
>
> http://docs.google.com/View?id=dfs2skx2_4g3s5f857
I just noticed another nit. Your proposal says "interface IDBIndex { }; //
Unchanged" but the spec's IDBIndex interface includes "readonly attribut
On Tue, May 18, 2010 at 8:18 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 7:20 AM, Jeremy Orlow wrote:
> >> 10. You are allowed to have multiple transactions per database
> >> connection. However if they use overlapping tables, only the first one
> >> will receive events until it is finish
On Tue, May 18, 2010 at 7:20 AM, Jeremy Orlow wrote:
> Overall, I'm pretty happy with these changes. I support making these
> changes to the spec. Additional comments inline...
> On Tue, May 18, 2010 at 2:15 AM, Jonas Sicking wrote:
>>
>> Hi All,
>>
>> I, together with Ben Turner and Shawn Wils
Overall, I'm pretty happy with these changes. I support making these
changes to the spec. Additional comments inline...
On Tue, May 18, 2010 at 2:15 AM, Jonas Sicking wrote:
> Hi All,
>
> I, together with Ben Turner and Shawn Wilsher have been looking at the
> asynchronous API defined in the I
25 matches
Mail list logo