Re: Points of order on this WG

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

Received on Thursday, 25 June 2009 19:45:35 UTC