On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote:
On Thu, 25 Jun 2009, Doug Schepers wrote:
On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote:
The Web Storage specification is someone dead-locked right now due
to the
lack of consensus on whether to use SQL or not.
I don't buy this argument for an instant, and I'd be very surprised
if
anyone in the WebApps WG did. This specification was published as
specified because it matched the behavior (more or less) of an
implementation (WebKit), and it's disingenuous to pretend that that
doesn't set a precedent for the future development of the
specification.
Let's be frank: there is good reason to specify and standardize
something that exists in a browser, because there is implementation
experience, and opportunity for widespread adoption, which is often
good; this is especially so with an implementation in a widespread
open-source engine like WebKit, because it can be reused. I don't
find
fault with that premise.
But just because it's been implemented doesn't mean it's the
correct or
best (or even a good) solution. There is less justification for
insisting on a single solution when it's only been implemented in one
browser engine, and only just recently. There's little evidence that
this will work well for other implementers, nor that this is the
solution that works best for content developers.
I cannot take seriously a claim that a spec can't be changed due to a
"lack of consensus" when the claimant has openly and repeatedly
indicated a disinterest in consensus. So, the only conclusion I can
draw
is that the spec is currently in a holding pattern to allow the
currently specified solution to gain defacto weight through real-
world
content, and possibly garner premature implementations before it is
even
in LC, thus making it all but impossible to change. As Kyle Weems
put
it: Deny, Delay, Too Late.
I think there may have been some misunderstanding about what I said
above
(possibly because of my typo; s/someone/somewhat/).
When I say that the Web Storage spec is deadlocked, I mean that as it
stands, it isn't acceptable, since it doesn't represent what at
least one
major vendor (Mozilla) wants, but that there haven't been any
alternative
proposals that have gained widespread approval either, and so I
don't know
how to move the spec forward. (I've been working with Mozilla off-
line to
try to resolve this, but do not yet have a solution.)
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]).
There is no attempt on my part to force anything through de-facto
implementations; it is in fact the lack of vendors willing to
implement
what is in the spec that is keeping it in a holding pattern. There
is no
claim that Web Storage can't be changed; indeed, I claim that it
_must_ be
changed, it's just that I'm not sure what it should be changed _to_.
In any case, adding a new feature to a spec whose future is uncertain
isn't a good idea because it means that the new feature's progress
is tied
to the uncertain future of the rest of the spec. Thus, my
recommendation
to Nikunj would be to create a new WG deliverable, not one tied to the
fate of the SQL Database section.
Nikunj has asked that his proposal be given equal weight and
consideration. While I'm not sure that's possible even now, because
of
the existing implementation, I personally think it is reasonable to
give
him a platform to demonstrate the relative merits of his alternate
proposal.
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.
[1]
http://www.oracle.com/technology/products/berkeley-db/pdf/berkeley-db-family-datasheet.pdf
