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

Re: Points of order on this WG

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 26 Jun 2009 10:42:09 -0700
Cc: Jonas Sicking <jonas@sicking.cc>
Message-Id: <0298B1E0-2232-4568-9AAF-069D2BF8443D@oracle.com>
To: public-webapps WG <public-webapps@w3.org>
On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote:

> 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.

You could implement SQL API on top of Berkeley DB as some have in the  
past. I am not super confident that the whole thing can work out with  
JavaScript overhead, but that may be just my perception of JS. This  
may be one of those conclusions that can only be made after a painful  
implementation exercise.
Received on Friday, 26 June 2009 17:44:22 UTC

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