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

Re: Points of order on this WG

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 25 Jun 2009 17:23:01 -0700
Message-ID: <63df84f0906251723q27328e68x8f536736c79aad49@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: Ian Hickson <ian@hixie.ch>, Doug Schepers <schepers@w3.org>, public-webapps WG <public-webapps@w3.org>, Charles McCathieNevile <chaals@opera.com>, Arthur Barstow <art.barstow@nokia.com>, Jeff Mischkinsky <JEFF.MISCHKINSKY@oracle.com>
On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R.
Mehta<nikunj.mehta@oracle.com> wrote:
> On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote:
> I have proposed to Mozilla a solution that provides access to an organized
> key-value database such as that provided in the (open source) Berkeley DB.
> In essence, a database is a simple B-tree - it keeps keys sorted and permits
> duplicate keys. It is able to find a key or a key prefix, which enables
> efficient searching through a very large number of items. If we are
> ambitious (i.e., need more functionality), we can add indexes and joins to
> this spec. There is unlikely to be an interoperability nightmare, such as
> that which is the most likely outcome with SQL, it does not mandate the use
> of any query language, and there is at least 40 years of experience with it,
> including in highly resource-constrained environments. (There are 200
> million copies of Berkeley DB in deployment [1]).

This is what so far seems like the best solution to me. I.e. something
that is more backend-ish than what a SQL API would be.

I'd love to see something that allows you to implement a SQL API on
top of. But that also allows you to implement something like MungoDB
very effectively.

>> I think Nikunj's proposal definitely is worthy of being persued, just like
>> the working group is persuing dozens of other proposals like XHR, CORS,
>> Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't
>> believe it really fits into the Web Storage spec (if anything, I think we
>> should split Web Storage into two further specs, not add a third wholly
>> independent feature to it). However, I would definitely support an FPWD
>> publication of Nikunj's proposal, as I have for other proposals.
> That is encouraging. I will be glad to edit an FPWD that includes B-tree,
> interception, and programmable cache, if the WG so prefers.

What I don't understand is, why does interception (I assume you mean
HTTP interception?) and programmable cache, belong in the same spec as
a B-tree?

/ Jonas
Received on Friday, 26 June 2009 00:24:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC