- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Fri, 26 Jun 2009 10:35:14 -0700
- To: public-webapps WG <public-webapps@w3.org>
- Cc: Maciej Stachowiak <mjs@apple.com>
- Message-Id: <D3E1F55C-9B8C-4412-9FC9-6CDE605965BA@oracle.com>
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 UTC