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