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

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.

I'm pretty sure this is decreasing ease of use any way you measure it.  And
that's mostly based on me personally having spent several days coding up
stuff with IndexedDB + talking to others who have doen the same.

J