On Jun 26, 2009, at 10:56 AM, Jeremy Orlow wrote:
On Fri, Jun 26, 2009 at 10:26 AM, Nikunj R. Mehta <nikunj.me...@oracle.com
> wrote:
Please don't skimp on due diligence before making such strong
statements. It creates unnecessary friction. More details below.
Similarly, I'd ask you to make your points clearer and to read what
others say more closely. You didn't address Maciej's points very
well, and I think they're definitely worth addressing.
I understand your point, even though I don't think I missed anything
in Maciej's comments, unless you want me to give sentence by sentence
and word by word clarifications. Still, I can try one more time. If I
miss this time, it is not intentional, and you can just ask me to
clarify.
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].
This is the type of thing I'd expect you to say had those links
clearly stated GPL, LGPL, etc compatibility. Am I missing it?
Because I don't see anything that makes it clear.
Oracle's license is what it is. I don't see why I should commit to
offering it under GPL or LGPL.
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.
What do you mean by your mileage may vary? Are you saying that
perhaps it is exactly as Maciej said?
If you have a closed source browser then Berkeley DB will require
commercial licensing. If your product is open source, then Berkeley DB
is free for you. If you are somewhere in between, then you need to ask
your lawyers. If you need something from Oracle, then by all means I
can help you with that.
Before believing Maciej, you might do well to read the links I sent in
my previous email, or ask your lawyers to review the license. I
understand that it is more work for you, but Oracle's at least helping
to the extent it can.
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.
Yes, b-trees (or some variant like b+trees) are used under the hood
by basically every database. LocalStorage/SessionStorage could
easily be implemented via b-tree's. The underlying implementation
really doesn't matter here.
What does matter is that localStorage and sessionStorage are a
simplified version of what you're proposing. That's what Maciej is
bringing up here.
I have already said that b-trees can subsume session and local
storage, not that I want to do it. However, Berkeley DB, when seen in
the context of secondary databases, join cursors, and transactions,
goes far beyond Local/Session storage.
If you are interested in an API that allows storage of multiple fields
and queries that work on individual field values, then we may have to
consider an API similar to Berkeley DB Java Edition's JPA API.
