Re: Points of order on this WG

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.

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.

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.

Regards,
Maciej

Received on Friday, 26 June 2009 05:50:11 UTC