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
Hi All,
I, together with Ben Turner and Shawn Wilsher have been looking at the
asynchronous API defined in the IndexDB specification and have a set
of changes to propose. The main goal of these changes is to simplify
the API that we expose to authors, making it easier for them to work
with. Anothe
26 matches
Mail list logo
