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