Andrei Popescu proposed a couple naming changes to the interfaces within IndedexDB deep within the "[IndexDB] Proposal for async API changes" thread [1].

One of the proposals was to change the "Request" suffix that's used for all the asynchronous interfaces (but not necessarily the IDBRequest object, since that's a bit different).

The voices are Andrei, Shawn, Jonas, and Jeremy in that order:

> >>> - The "Request" suffix is now used to denote the asynchronous versions
> >>> of the API interfaces. These interfaces aren't actually Requests of
> >>> any kind, so I would like to suggest changing this suffix. In fact, if
> >>> the primary usage of this API is via its async version, we could even
> >>> drop this suffix altogether and just add "Sync" to the synchronous
> >>> versions?
> >>
> >> I agree that Request seems confusing and seems to be contrary to what other
> >> specs use.  We should try to follow what other specs do here.
> >
> > Agreed on both accounts. There unfortunately isn't much in the way of
> > precedence here. There are three other specs to look at here, which
> > specify API for both workers and main thread.
> >
> > * Web Workers spec
> > http://www.whatwg.org/specs/web-workers/current-work/ This spec
> > doesn't actually use different interfaces for workers and main thread.
> > * File API http://dev.w3.org/2006/webapi/FileAPI/ Specifies FileReader
> > and FileReaderSync. The two interfaces are separate and doesn't
> > inherit from a common base
> > * WebSQLDatabase http://dev.w3.org/html5/webdatabase/ Specifies
> > separate interfaces, like Database and DatabaseSync. The two
> > interfaces are separate and doesn't inherit from a common base.
> >
> > I think we should follow the same convention as File API and
> > WebSQLDatabase. There really isn't anything to be gained by having a
> > common base interface, it just makes the spec harder to read as
> > functionality is distributed between the base interface and the
> > sync/async interface.
> >
> > I additionally like the naming convention. The async interfaces is
> > probably the interface that people will use first. Additionally that
> > interface is available both to workers and to the main thread. So it
> > makes sense to give the async interface the simpler name.
>
> Agreed on all counts.  I would add that, if we did decide to keep
> base interfaces, we could always suffix them with Base (which I
> think makes it more clear they're base interfaces)...but it sounds
> like that might not be necessary.

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0801.html