Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object

On Tue, Jan 11, 2011 at 2:22 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Mon, Jan 10, 2011 at 9:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Dec 14, 2010 at 12:13 PM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> >
>> > On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> >>
>> >> On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow <jorlow@chromium.org>
>> >> wrote:
>> >>>
>> >>> Btw, I forgot to mention IDBDatabase.transaction which I definitely
>> >>> think should take an options object as well.
>> >>
>> >> Hmm.. I think we should make the first argument required, I actually
>> >> thought it was until I looked just now. I don't see what the use case is for
>> >> opening all tables.
>> >
>> > FWIW I'm finding that the majority of the IndexedDB code I read and
>> > write does indeed need to lock everything.  I'm also finding that most of
>> > the code I'm writing/reading won't be helped at all by defaulting to
>> > READ_ONLY...
>> >
>> >>
>> >> In fact, it seems rather harmful that the syntax which will result in
>> >> more lock contention is simpler than the syntax which is better optimized.
>> >
>> > But you're right about this.  So, if we're trying to force users to
>> > write highly parallelizable code, then yes the first arg probably should be
>> > required.  But if we're trying to make IndexedDB easy to use then actually
>> > the mode should probably be changed back to defaulting to READ_WRITE.
>> > I know I argued for the mode default change earlier, but I'm having
>> > second thoughts.  We've spent so much effort making the rest of the API easy
>> > to use that having points of abrasion like this seem a bit wrong.
>> >  Especially if (at least in my experience) the abrasion is only going to
>> > help a limited number of cases--and probably ones where the developers will
>> > pay attention to this without us being heavy-handed.
>>
>> I think "ease of use" is different from "few characters typed". For
>> example it's important that the API discourages bugs, for example by
>> making the code easy and clear to read. Included in that is IMHO to
>> make it easy to make the code fast.
>
> It won't make the cost fast.  It'll make it'll allow parallel execution.
>  Which will only matter if a developer is trying to do multiple reads at
> once and you have significant latency to your backend and/or it's heavily
> disk bound.  Which will only be true in complex web apps--the kind where a
> developer is going to be more conscious of various performance bottlenecks.
>  In other words, most of the time, defaulting to READ_ONLY will almost
> certainly have no visible impact in speed.

It also matters for the use cases of having background workers reading
from the same table, as well as any time the user opens two tabs to
the same page. The latter is something that I expect every web app
would care about.

/ Jonas

Received on Wednesday, 12 January 2011 22:14:54 UTC