On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehta<[email protected]> 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 think Nikunj's proposal definitely is worthy of being persued, just like >> the working group is persuing dozens of other proposals like XHR, CORS, >> Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't >> believe it really fits into the Web Storage spec (if anything, I think we >> should split Web Storage into two further specs, not add a third wholly >> independent feature to it). However, I would definitely support an FPWD >> publication of Nikunj's proposal, as I have for other proposals. > > That is encouraging. I will be glad to edit an FPWD that includes B-tree, > interception, and programmable cache, if the WG so prefers. What I don't understand is, why does interception (I assume you mean HTTP interception?) and programmable cache, belong in the same spec as a B-tree? / Jonas
