On Tue, Jul 27, 2010 at 4:38 PM, Jonas Sicking wrote:
> On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow wrote:
> > On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking
> wrote:
> >>
> >> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow
> wrote:
> >> >> >> And is it
> >> >> >> only possible to lock exist
On Tue, Jul 27, 2010 at 3:14 AM, Jeremy Orlow wrote:
> On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking wrote:
>>
>> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow wrote:
>> >> >> And is it
>> >> >> only possible to lock existing rows, or can you prevent new records
>> >> >> from being created?
>>
On Tue, Jul 27, 2010 at 12:22 AM, Jonas Sicking wrote:
> On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow wrote:
> >> >> And is it
> >> >> only possible to lock existing rows, or can you prevent new records
> >> >> from being created?
> >> >
> >> > There's no way to lock yet to be created rows sinc
On Sat, Jul 24, 2010 at 8:29 AM, Jeremy Orlow wrote:
>> >> And is it
>> >> only possible to lock existing rows, or can you prevent new records
>> >> from being created?
>> >
>> > There's no way to lock yet to be created rows since until a transaction
>> > ends, its effects cannot be made visible t
On Fri, Jul 23, 2010 at 4:21 PM, Jonas Sicking wrote:
> On Fri, Jul 23, 2010 at 8:09 AM, Nikunj Mehta wrote:
> >
> > On Jul 22, 2010, at 11:27 AM, Jonas Sicking wrote:
> >
> >> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta
> wrote:
> >>>
> >>> On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>
On Fri, Jul 23, 2010 at 8:09 AM, Nikunj Mehta wrote:
>
> On Jul 22, 2010, at 11:27 AM, Jonas Sicking wrote:
>
>> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta wrote:
>>>
>>> On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>>>
From: jor...@google.com [mailto:jor...@google.com] On Behalf
On Jul 22, 2010, at 11:27 AM, Jonas Sicking wrote:
> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta wrote:
>>
>> On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>>
>>>
>>> From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
>>> Sent: Thursday, July 15, 2010 8:41 AM
>>
On Thu, Jul 22, 2010 at 8:39 PM, Pablo Castro wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Thursday, July 22, 2010 5:25 PM
>
> >> >> Regarding deadlocks, that's right, the implementation cannot
> determine if
> >> >> a deadlock will occur ahead of time. Sophisticated implementa
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, July 22, 2010 5:30 PM
>> On Thu, Jul 22, 2010 at 5:26 PM, Pablo Castro
>> wrote:
>> >
>> > From: Jonas Sicking [mailto:jo...@sicking.cc]
>> > Sent: Thursday, July 22, 2010 5:18 PM
>> >
>> >>> > The author doesn't explicitly specify w
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, July 22, 2010 5:25 PM
>> >> Regarding deadlocks, that's right, the implementation cannot determine if
>> >> a deadlock will occur ahead of time. Sophisticated implementations could
>> >> track locks/owners and do deadlock detection, a
On Thu, Jul 22, 2010 at 5:26 PM, Pablo Castro
wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Thursday, July 22, 2010 5:18 PM
>
>>> > The author doesn't explicitly specify which rows to lock. All rows that
>>> > you "see" become locked (e.g. through get(), put(), scanning with a
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, July 22, 2010 5:18 PM
>> > The author doesn't explicitly specify which rows to lock. All rows that
>> > you "see" become locked (e.g. through get(), put(), scanning with a
>> > cursor, etc.). If you start the transaction as read-onl
On Thu, Jul 22, 2010 at 5:18 PM, Jeremy Orlow wrote:
> On Thu, Jul 22, 2010 at 7:41 PM, Pablo Castro
> wrote:
>>
>> From: Jonas Sicking [mailto:jo...@sicking.cc]
>> Sent: Thursday, July 22, 2010 11:27 AM
>>
>> >> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta
>> >> wrote:
>> >> >
>> >> > On Jul 1
On Thu, Jul 22, 2010 at 7:41 PM, Pablo Castro wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Thursday, July 22, 2010 11:27 AM
>
> >> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta
> wrote:
> >> >
> >> > On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
> >> >
> >> >>
> >> >> From:
On Thu, Jul 22, 2010 at 4:41 PM, Pablo Castro
wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Thursday, July 22, 2010 11:27 AM
>
>>> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta wrote:
>>> >
>>> > On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>>> >
>>> >>
>>> >> From: jor...@
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Thursday, July 22, 2010 11:27 AM
>> On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta wrote:
>> >
>> > On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>> >
>> >>
>> >> From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
>> >>
On Thu, Jul 22, 2010 at 3:43 AM, Nikunj Mehta wrote:
>
> On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>
>>
>> From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
>> Sent: Thursday, July 15, 2010 8:41 AM
>>
>> On Thu, Jul 15, 2010 at 4:30 PM, Andrei Popescu wrote:
>> O
On Jul 16, 2010, at 5:41 AM, Pablo Castro wrote:
>
> From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
> Sent: Thursday, July 15, 2010 8:41 AM
>
> On Thu, Jul 15, 2010 at 4:30 PM, Andrei Popescu wrote:
> On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow wrote:
>> On Thu
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Thursday, July 15, 2010 8:41 AM
On Thu, Jul 15, 2010 at 4:30 PM, Andrei Popescu wrote:
On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow wrote:
> On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu wrote:
>>
>> On Thu,
On Thu, Jul 15, 2010 at 4:30 PM, Andrei Popescu wrote:
> On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow wrote:
> > On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu
> wrote:
> >>
> >> On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow
> wrote:
> >> >> Nikunj, could you clarify how locking works for th
On Thu, Jul 15, 2010 at 3:24 PM, Jeremy Orlow wrote:
> On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu wrote:
>>
>> On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow wrote:
>> >> Nikunj, could you clarify how locking works for the dynamic
>> >> transactions proposal that is in the spec draft right n
On Thu, Jul 15, 2010 at 3:09 PM, Andrei Popescu wrote:
> On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow wrote:
> >> Nikunj, could you clarify how locking works for the dynamic
> >> transactions proposal that is in the spec draft right now?
> >
> > I'd definitely like to hear what Nikunj originall
On Thu, Jul 15, 2010 at 9:50 AM, Jeremy Orlow wrote:
> On Thu, Jul 15, 2010 at 2:37 AM, Jonas Sicking wrote:
>>
>> On Wed, Jul 14, 2010 at 6:05 PM, Pablo Castro
>> wrote:
>> >
>> > From: Jonas Sicking [mailto:jo...@sicking.cc]
>> > Sent: Wednesday, July 14, 2010 5:43 PM
>> >
>> > On Wed, Jul 14,
On Thu, Jul 15, 2010 at 2:37 AM, Jonas Sicking wrote:
> On Wed, Jul 14, 2010 at 6:05 PM, Pablo Castro
> wrote:
> >
> > From: Jonas Sicking [mailto:jo...@sicking.cc]
> > Sent: Wednesday, July 14, 2010 5:43 PM
> >
> > On Wed, Jul 14, 2010 at 5:03 PM, Pablo Castro
> > wrote:
> >>
> >> From: Jonas
On Wed, Jul 14, 2010 at 6:05 PM, Pablo Castro
wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Wednesday, July 14, 2010 5:43 PM
>
> On Wed, Jul 14, 2010 at 5:03 PM, Pablo Castro
> wrote:
>>
>> From: Jonas Sicking [mailto:jo...@sicking.cc]
>> Sent: Wednesday, July 14, 2010 12:07 AM
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Wednesday, July 14, 2010 5:43 PM
On Wed, Jul 14, 2010 at 5:03 PM, Pablo Castro
wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Wednesday, July 14, 2010 12:07 AM
>
>> I think what I'm struggling with is how dynamic transaction
On Wed, Jul 14, 2010 at 5:03 PM, Pablo Castro
wrote:
>
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Wednesday, July 14, 2010 12:07 AM
>
>>> > Dynamic transactions:
>>> > I see that most folks would like to see these going away. While I like
>>> > the predictability and simplifications
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Wednesday, July 14, 2010 12:10 AM
On Wed, Jul 14, 2010 at 3:52 AM, Pablo Castro
wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Andrei Popescu
Sent: Monday, July 1
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Wednesday, July 14, 2010 12:07 AM
>> > Dynamic transactions:
>> > I see that most folks would like to see these going away. While I like the
>> > predictability and simplifications that we're able to make by using static
>> > scopes for trans
On Wed, Jul 14, 2010 at 9:28 AM, Andrei Popescu wrote:
> On Wed, Jul 14, 2010 at 5:21 PM, Jonas Sicking wrote:
>> On Wed, Jul 14, 2010 at 5:20 AM, Andrei Popescu wrote:
>>> Hi,
>>>
>>> I would like to propose that we update the current spec to reflect all
>>> the changes we have agreement on. We
On Wed, Jul 14, 2010 at 5:21 PM, Jonas Sicking wrote:
> On Wed, Jul 14, 2010 at 5:20 AM, Andrei Popescu wrote:
>> Hi,
>>
>> I would like to propose that we update the current spec to reflect all
>> the changes we have agreement on. We can then iteratively review and
>> make edits as soon as the r
On Wed, Jul 14, 2010 at 5:20 AM, Andrei Popescu wrote:
> Hi,
>
> I would like to propose that we update the current spec to reflect all
> the changes we have agreement on. We can then iteratively review and
> make edits as soon as the remaining issues are solved. Concretely, I
> would like to che
On Wed, Jul 14, 2010 at 3:10 AM, Jeremy Orlow wrote:
> For example, with dynamic transactions you can get into live-lock
> situations.
I'm particularly opposed to dynamic transactions for just this reason.
We would clearly have to throw an exception or call the error callback
if we detect liveloc
On Wed, Jul 14, 2010 at 1:20 PM, Andrei Popescu wrote:
> Hi,
>
> I would like to propose that we update the current spec to reflect all
> the changes we have agreement on. We can then iteratively review and
> make edits as soon as the remaining issues are solved. Concretely, I
> would like to ch
Hi,
I would like to propose that we update the current spec to reflect all
the changes we have agreement on. We can then iteratively review and
make edits as soon as the remaining issues are solved. Concretely, I
would like to check in a fix for
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9975
On Wed, Jul 14, 2010 at 3:52 AM, Pablo Castro wrote:
>
> From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
> On Behalf Of Andrei Popescu
> Sent: Monday, July 12, 2010 5:23 AM
>
> Sorry I disappeared for a while. Catching up with this discussion was an
> interesting exercis
Hi Pablo,
First off, thanks for your comments! (Probably too much) details below.
On Tue, Jul 13, 2010 at 7:52 PM, Pablo Castro
wrote:
>
> From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
> Behalf Of Andrei Popescu
> Sent: Monday, July 12, 2010 5:23 AM
>
> Sorry I d
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Andrei Popescu
Sent: Monday, July 12, 2010 5:23 AM
Sorry I disappeared for a while. Catching up with this discussion was an
interesting exercise...there is no particular message in this thread I can
respond
Nikunj,
On Fri, Jul 9, 2010 at 8:21 PM, Nikunj Mehta wrote:
>
>
> From my examples, it was clear that we need different object stores to be
> opened in different modes. Currently dynamic scope supports this use case,
> i.e., allow mode specification on a per object-store basis. Therefore, unles
On Fri, Jul 9, 2010 at 6:27 PM, Jonas Sicking wrote:
>> I also did not hear from you about explicit commits. Did that mean that you
>> agree with that part of my proposal? There are several examples where it
>> makes sense to explicitly commit, although it is automatic in some cases.
>
> I haven
On Fri, Jul 9, 2010 at 12:50 PM, Nikunj Mehta wrote:
>
> On Jul 10, 2010, at 12:29 AM, Jonas Sicking wrote:
>
>> On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta wrote:
>>> We would not make dynamic transactions be the default since they would
>>> produce more concurrency than static scoped transact
On Fri, Jul 9, 2010 at 12:21 PM, Nikunj Mehta wrote:
>>>
>>> I don't think it's even possible with the current API since
>>> openTransaction() takes a list of objectStore names but a single mode.
>>
>> Indeed. We could allow static transactions to use different lock
>> levels for different ob
On Fri, Jul 9, 2010 at 11:44 AM, Nikunj Mehta wrote:
>
> On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote:
>
>> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>>>
>>>
>>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
>
On Fri, Jul 9, 2010 at 11:27 AM, Nikunj Mehta wrote:
>
> On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
>
> 2. Provide a catalog object that can be used to atomically add/remove
> object stores and indexes as well as modify version.
It seems to me that a catalog object doesn't
On 7/9/2010 12:50 PM, Nikunj Mehta wrote:
The point is that we are talking of leaving out dynamic scope in v1, while, in the same
vein, talking of making READ_ONLY the default _because_ it produces "good"
performance. That is, IMHO, contradictory.
Dynamic scope == dynamic transactions, correct
On 7/9/2010 11:05 AM, Nikunj Mehta wrote:
We would not make dynamic transactions be the default since they would produce
more concurrency than static scoped transactions, correct?
I'm still of the opinion that dynamic transactions are a bad idea
because it's too easy to hold a transaction open
Hi Nikunj,
On Fri, Jul 9, 2010 at 7:31 PM, Nikunj Mehta wrote:
> Andrei,
>
> Pejorative remarks about normative text don't help anyone. If you think that
> the spec text is not clear or that you are unable to interpret it, please say
> so. The text about dynamic scope has been around for long e
On Jul 10, 2010, at 12:29 AM, Jonas Sicking wrote:
> On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta wrote:
>> We would not make dynamic transactions be the default since they would
>> produce more concurrency than static scoped transactions, correct?
>> On Jul 7, 2010, at 12:57 PM, Jonas Sicking
On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote:
>
> One of our main points was to make getting objectStore
> objects a synchronous operation as to avoid having to nest multiple
> levels of asynchronous calls. Compare
>
> var req = db.openObjectStore("foo", trans);
On Jul 8, 2010, at 4:17 AM, Shawn Wilsher wrote:
> On 7/6/2010 6:31 PM, Nikunj Mehta wrote:
>> To begin with, 10052 shuts down the "users" of the database completely when
>> only one is changing its structure, i.e., adding or removing an object
>> store. How can we make it less draconian? Secondl
On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote:
> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>>
>>
>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
>>>
>>> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote:
>>>
On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta wrote:
> We would not make dynamic transactions be the default since they would
> produce more concurrency than static scoped transactions, correct?
> On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
I'm not sure I understand the question. We would u
Andrei,
Pejorative remarks about normative text don't help anyone. If you think that
the spec text is not clear or that you are unable to interpret it, please say
so. The text about dynamic scope has been around for long enough and no one so
far mentioned a problem with them.
Nikunj
On Jul 7,
On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
2. Provide a catalog object that can be used to atomically add/remove
object stores and indexes as well as modify version.
>>>
>>> It seems to me that a catalog object doesn't really provide any
>>> functionality over the proposal in bu
We would not make dynamic transactions be the default since they would produce
more concurrency than static scoped transactions, correct?
On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
>>> Unless we're planning on making all
>>> transactions dynamic (I hope not), locks have to be grabbed when
On Fri, Jul 9, 2010 at 3:21 AM, Andrei Popescu wrote:
> On Thu, Jul 8, 2010 at 8:27 PM, Jonas Sicking wrote:
>> On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote:
>>> Hi Jonas,
>>>
>>> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote:
On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu
On Thu, Jul 8, 2010 at 8:27 PM, Jonas Sicking wrote:
> On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote:
>> Hi Jonas,
>>
>> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote:
>>> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
On Wed, Jul 7, 2010 at 8:27 AM, Jonas Si
On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote:
> Hi Jonas,
>
> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote:
>> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>>>
>>>
>>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
On Tue, Jul 6, 2010 at 6:31 PM, Nikunj
On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote:
> Hi Jonas,
>
> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote:
>> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>>>
>>>
>>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
On Tue, Jul 6, 2010 at 6:31 PM, Nikunj
Hi Jonas,
On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote:
> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>>
>>
>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
>>>
>>> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
>>> > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking
On 7/7/2010 12:27 AM, Jonas Sicking wrote:
This interface allows asynchronously requesting more objectStores to
be locked. The author must take care whenever calling openObjectStores
that the request might fail due to deadlocks.
But as previously stated, I think this adds too much complexity an
On 7/6/2010 6:31 PM, Nikunj Mehta wrote:
To begin with, 10052 shuts down the "users" of the database completely when
only one is changing its structure, i.e., adding or removing an object
store. How can we make it less draconian? Secondly, I don't see how that
approach can produce atomic changes
On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote:
>
>
> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
>>
>> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
>> > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote:
>> >>
>> >> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta
>> >> w
On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote:
> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
> > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote:
> >>
> >> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta
> wrote:
> >> > Hi folks,
> >> >
> >> > There are several unimplemented pro
On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote:
> On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote:
>>
>> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta wrote:
>> > Hi folks,
>> >
>> > There are several unimplemented proposals on strengthening and
>> > expanding IndexedDB. The reason I have
On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote:
> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta wrote:
> > Hi folks,
> >
> > There are several unimplemented proposals on strengthening and
> > expanding IndexedDB. The reason I have not implemented them yet is
> > because I am not convinced th
On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta wrote:
> Hi folks,
>
> There are several unimplemented proposals on strengthening and
> expanding IndexedDB. The reason I have not implemented them yet is
> because I am not convinced they are necessary in toto. Here's my
> attempt at explaining why. I
67 matches
Mail list logo
