W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

[Bug 9790] New: Request is not a good suffix for all the async interfaces in IndexedDB

From: <bugzilla@jessica.w3.org>
Date: Fri, 21 May 2010 16:28:05 +0000
To: public-webapps@w3.org
Message-ID: <bug-9790-2927@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790

           Summary: Request is not a good suffix for all the async
                    interfaces in IndexedDB
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: nikunj.mehta@oracle.com
        ReportedBy: jorlow@chromium.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 21 May 2010 16:28:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT