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:26:30 -0700
Cc: Jonas Sicking <jonas@sicking.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>
Message-Id: <DF412185-6A5E-458E-878B-FAE71FBC0EDD@oracle.com>
To: Maciej Stachowiak <mjs@apple.com>
Please don't skimp on due diligence before making such strong  
statements. It creates unnecessary friction. More details below.

On Jun 25, 2009, at 10:49 PM, Maciej Stachowiak wrote:

> 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.
>
> I doubt you can efficiently or correctly implement SQL on top of a  
> Berkeley-DB-style API.

If you are worrying, that's great; we can address your worries.

Just take a look at the top two hits for "MySQL Berkeley DB". The  
first one talks about MySQL with the BDB storage engine - so yes, you  
can correctly implement SQL on top of Berkeley DB [1]. The second one  
talks about MySQL discontinuing BDB support due to extra-technical  
reasons, so there are no efficiency reasons either [2].

>
> As a side note, it should be noted Berkeley DB itself could not be  
> used by WebKit or Gecko to implement the spec, because even though  
> it is open source, the license is not compatible with the LGPL. It  
> seems unlikely that non-open-source browser engines could use it  
> either, unless they are willing to pay Oracle for a commercial  
> license. So it's very important for the spec to be clear and  
> detailed, because everyone will have to implement it from scratch.

Huh? what? I hope you had read Oracle's BDB license document [3] and  
open source FAQ [4]. IANAL, but I can get answers for your specific  
concerns in the context of open source Berkeley DB. AFAICT, someone  
like Mozilla would not face any trouble with the open source license  
of Berkeley DB. YMMV.

>
> It's also not clear to me if a BDB-level API is sufficient for  
> developer needs. As I understand it, it's basically a giant  
> dictionary with unstructured keys and values. So it's not providing  
> much over LocalStorage, except for prefix matching and the ability  
> to hold large amounts of records or records that are individually  
> large. There's no way to efficiently query by one of several fields,  
> as I understand it.

I trust that you are relatively new to storing data with B-trees. They  
are at the heart of Oracle's indices so efficiency is out of question.  
If you are wondering how can people store complex data items with  
multiple fields and repeating values, look at Berkeley DB Java  
Edition, which supports the EJB 3 persistence model [5]. FYI, there is  
no significant difference between the APIs of BDB Java Edition and the  
original BDB. They also have identical licensing requirements.

[1] http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html
[2] http://www.linux.com/archive/articles/56835
[3] http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html
[4] http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html
[5] http://www.oracle.com/technology/products/berkeley-db/je/index.html
Received on Friday, 26 June 2009 17:29:10 GMT

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