W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Points of order on this WG

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 26 Jun 2009 10:35:14 -0700
Cc: Maciej Stachowiak <mjs@apple.com>
Message-Id: <D3E1F55C-9B8C-4412-9FC9-6CDE605965BA@oracle.com>
To: public-webapps WG <public-webapps@w3.org>
On Jun 25, 2009, at 4:25 PM, Maciej Stachowiak wrote:

>
> On Jun 25, 2009, at 12:42 PM, Nikunj R. Mehta wrote:
>
>>>
>>> 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.
>>
>
> It seems to me that Berkley DB style database storage, and request  
> interception / programmable cache are orthogonal ideas and should  
> arguably be separate drafts. I would assume request interception and  
> programmable cache are usable regardless of what client-side storage  
> APIs are available, much as HTML5 Application Cache is independent  
> of these APIs. If anything, it seems more closely related to  
> AppCache than to any proposed storage solution.
>

I don't have a preference either way. Request interception and  
programmable cache belong in a single spec. We could put Structured  
storage in a separate spec on its own.

> Regards,
> Maciej
>
Received on Friday, 26 June 2009 17:37:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT