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