Re: Points of order on this WG

On Jun 26, 2009, at 10:56 AM, Jeremy Orlow wrote:

> On Fri, Jun 26, 2009 at 10:26 AM, Nikunj R. Mehta <nikunj.mehta@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.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].
>
> 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.