Re: Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)
On Apr 23, 2009, at 1:04 PM, Doug Schepers wrote: Hi, Folks- I discussed this a bit with Nikunj offline, in the context of the charter wording. He and I both agreed that the scope of the charter was too narrow (that was my fault; I changed the wording to reflect the abstract of the current Web Storage spec, and I probably shouldn't have), but we also agreed that the spec itself is higher profile and more important than the wording in the charter. Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON- based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. Rather than change the charter (which would require everyone who's already rejoined to re-rejoin at the simplest, and might require another AC review at the worst), Nikunj offered that he would be satisfied if more generic wording were put in the charter, and highlighted as an issue. To be precise, I suggested that we can table the charter issue for now, and emphasize in the spec that we haven't finalized SQL as the only structured storage access solution. Preferably, the current Section 4 would be renamed as [[ Structured Storage ]] with the following wording in it: [[ The working group is currently debating whether SQL is the right abstraction for structured storage. ]] I would propose something like, This specification currently contains wording specific to a SQL or name-value pair storage solution, but the WebApps WG is discussing other structured storage alternatives that may better match the use cases and requirements. I leave it up to Nikunj to provide wording that would satisfy him. If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. Art, Chaals, care to chime in? Other comments on this matter? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Jonas Sicking wrote (on 4/21/09 6:22 PM): Hmm.. I tend to agree. Using an SQL database is only one possible solution that we should be examining. I would rather say that we should provide storage for structured data inside the UA. I'm not a fan of calling out neither SQL or name-value pair storage. At the same time I'm not sure that I care that much about it, as long as we can change the draft later in case the spec takes a different turn than the current drafts. / Jonas On Tue, Apr 21, 2009 at 2:44 PM, Nikunj Mehtanikunj.me...@oracle.com wrote: Apparently the new charter [1] that forces everyone to re-join the WG also lists among its deliverables as WebStorage with the explanation that WebStorage is two APIs for client-side data storage in Web applications: a name- value pair system, and a database system with a SQL frontend Clearly, if the WD of WebStorage has in its abstract something more general, the charter should not be so specific. I now understand that this new piece of text made its way into the charter recently. The last message I can see about charter change for WebApps [1] only talks about adding WebWorkers. Apparently other changes were also made, but no diff provided to members about the charter change proposal. Can you throw some light on this? Nikunj [1] http://www.w3.org/2009/04/webapps-charter [2] http://www.w3.org/mid/3e428ec7-1960-4ece-b403-827ba47fe...@nokia.comian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. Done.
Re: Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)
On Apr 23, 2009, at 1:18 PM, Ian Hickson wrote: On Thu, 23 Apr 2009, Doug Schepers wrote: Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. If there is something that is more useful for Web authors as a whole than SQL, and if the browser vendors are willing to implement it, then the spec should use that, yes. (I don't know of anything that fits that criteria though. Most of the proposals so far have been things that are useful in specific scenarios, but aren't really generic solutions.) If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. The draft got published today, so it's too late to change the high- profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? I don't want to discredit the standardization efforts for SQL in WebStorage. Yet, this spec is just in its FPWD. Won't we be better off coming to a conclusion on the issue of the set of storage solutions and access techniques for the same soon after the WD is published? By tomorrow, I commit to send a concrete proposal for solving storage needs (besides SQL) that I believe browser vendors would be able to (and hopefully willing to) implement. I am giving my current draft a thorough read before I send it off to the WG. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: Web Storage Scope and Charter
Hi, Nikunj- Nikunj Mehta wrote (on 4/24/09 2:24 AM): On Apr 23, 2009, at 1:04 PM, Doug Schepers wrote: Rather than change the charter (which would require everyone who's already rejoined to re-rejoin at the simplest, and might require another AC review at the worst), Nikunj offered that he would be satisfied if more generic wording were put in the charter, and highlighted as an issue. Sorry, typo... I meant to say, if more generic wording were put in the *spec*. (Depending on the outcome of the WG's decision on the matter, we could change the charter language during our next rechartering, too, if necessary.) To be precise, I suggested that we can table the charter issue for now, and emphasize in the spec that we haven't finalized SQL as the only structured storage access solution. Yes, thanks for the correction... my original sentence didn't make much sense. :) Preferably, the current Section 4 would be renamed as [[ Structured Storage ]] with the following wording in it: [[ The working group is currently debating whether SQL is the right abstraction for structured storage. ]] So, the phrase above is already in the spec... the only thing you're asking now is for Section 4 to be renamed, right? Seems pretty minor. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Web Storage Scope and Charter
On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote: On Thu, 23 Apr 2009 22:18:40 +0200, Ian Hickson i...@hixie.ch wrote: The draft got published today, so it's too late to change the high- profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. I am puzzled that you feel that specifying the semantics for the SQL dialect would be straightforward. We have no experience of using more than a single database implementation for WebStorage. Its kind of interesting that the WG is attempting to standardize that which has no more than a single implementation. Nikunj
Re: Web Storage Scope and Charter
On Apr 23, 2009, at 11:34 PM, Doug Schepers wrote: Nikunj Mehta wrote (on 4/24/09 2:24 AM): [snip] Preferably, the current Section 4 would be renamed as [[ Structured Storage ]] with the following wording in it: [[ The working group is currently debating whether SQL is the right abstraction for structured storage. ]] So, the phrase above is already in the spec... the only thing you're asking now is for Section 4 to be renamed, right? Seems pretty minor. Correct
Re: Web Storage Scope and Charter
On Apr 23, 2009, at 2:13 PM, Doug Schepers wrote: Hi, Ian- Ian Hickson wrote (on 4/23/09 4:18 PM): On Thu, 23 Apr 2009, Doug Schepers wrote: Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. If there is something that is more useful for Web authors as a whole than SQL, and if the browser vendors are willing to implement it, then the spec should use that, yes. (I don't know of anything that fits that criteria though. Most of the proposals so far have been things that are useful in specific scenarios, but aren't really generic solutions.) This seems to lead into a discussion of use cases and requirements. You don't include those in your draft... Do you have a UCR document that we could put on the wiki, like the one for Web Workers [1] (note that although I put that into the wiki, I pulled them from somewhere else, maybe the HTML wiki)? So, some of the requirements you're listing here are: * more useful for Web authors as a whole than SQL This is not a specific requirement * browser vendors are willing to implement it Neither is this * should have broad and scalable applicability And nor is this I have offered one set of suggestions, which are obviously a small and possibly narrow set of what might have gone in to the WG's thinking. If I had only one vote, I would cast it for a WebStorage requirement for seamless on-line/off-line data access. The first two are rather hard to quantify, and part of the process of writing a spec is to discover what these are. The best solution is not necessarily the most obvious one from the start, and after deeper examination, browsers implementers may be willing to implement something that didn't appeal to them at the beginning. (Any spec is better than no spec, so the fact that they may be willing to implement whatever the current spec says doesn't mean it's the best solution.) What are the other criteria you have in mind? Which other solutions have you looked at that don't meet these criteria? If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. The draft got published today, so it's too late to change the high- profile version of the spec. It's not too late at all. This group can publish as frequently as it wants, and we could have another WD up next week, with such a message in it. That would have an equally high profile. The overhead of this seems much less than that of changing the charter. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? We can do both: publish an updated version of the spec that says we're looking at various solutions, and examine the solutions that come in (as a result of broad review that opens that door). If we are able to come to an immediate conclusion, I'm all in favor of that. But Nikunj, at least, doesn't seem to think we are there yet, so I think it's worth reopening the larger issue. [1] http://www.w3.org/2008/webapps/wiki/Web_Workers Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Web Storage Scope and Charter
On Thu, 23 Apr 2009, Nikunj Mehta wrote: On Apr 23, 2009, at 11:34 PM, Doug Schepers wrote: Nikunj Mehta wrote (on 4/24/09 2:24 AM): [snip] Preferably, the current Section 4 would be renamed as [[ Structured Storage ]] with the following wording in it: [[ The working group is currently debating whether SQL is the right abstraction for structured storage. ]] So, the phrase above is already in the spec... the only thing you're asking now is for Section 4 to be renamed, right? Seems pretty minor. Correct Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Storage Scope and Charter
On Thu, 23 Apr 2009, Nikunj Mehta wrote: On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote: On Thu, 23 Apr 2009 22:18:40 +0200, Ian Hickson i...@hixie.ch wrote: The draft got published today, so it's too late to change the high-profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. I am puzzled that you feel that specifying the semantics for the SQL dialect would be straightforward. We have no experience of using more than a single database implementation for WebStorage. That's pretty much why it would be straightforward. Its kind of interesting that the WG is attempting to standardize that which has no more than a single implementation. Most things in the W3C get standardised (to LC or CR) before they have even one. Having one at all is generally considered a bonus. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Storage Scope and Charter
On Apr 23, 2009, at 11:51 PM, Ian Hickson wrote: On Thu, 23 Apr 2009, Nikunj Mehta wrote: On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote: On Thu, 23 Apr 2009 22:18:40 +0200, Ian Hickson i...@hixie.ch wrote: The draft got published today, so it's too late to change the high-profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. I am puzzled that you feel that specifying the semantics for the SQL dialect would be straightforward. We have no experience of using more than a single database implementation for WebStorage. That's pretty much why it would be straightforward. Its kind of interesting that the WG is attempting to standardize that which has no more than a single implementation. Most things in the W3C get standardised (to LC or CR) before they have even one. Having one at all is generally considered a bonus. :-) That does simplify things for me and should help the proposal I am to make tomorrow.
Re: Web Storage Scope and Charter
On Fri, 24 Apr 2009 08:32:31 +0200, Nikunj Mehta nikunj.me...@oracle.com wrote: On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote: FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. I am puzzled that you feel that specifying the semantics for the SQL dialect would be straightforward. I didn't say it would be straightforward. It might be, but I really wouldn't know. We have no experience of using more than a single database implementation for WebStorage. Its kind of interesting that the WG is attempting to standardize that which has no more than a single implementation. The draft specification was there before the implementation and there's a plug-in implementation (Gears) as well. It sees better to coordinate new APIs then to end up with four incompatible ones. -- Anne van Kesteren http://annevankesteren.nl/
Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)
Hi, Folks- I discussed this a bit with Nikunj offline, in the context of the charter wording. He and I both agreed that the scope of the charter was too narrow (that was my fault; I changed the wording to reflect the abstract of the current Web Storage spec, and I probably shouldn't have), but we also agreed that the spec itself is higher profile and more important than the wording in the charter. Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. Rather than change the charter (which would require everyone who's already rejoined to re-rejoin at the simplest, and might require another AC review at the worst), Nikunj offered that he would be satisfied if more generic wording were put in the charter, and highlighted as an issue. I would propose something like, This specification currently contains wording specific to a SQL or name-value pair storage solution, but the WebApps WG is discussing other structured storage alternatives that may better match the use cases and requirements. I leave it up to Nikunj to provide wording that would satisfy him. If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. Art, Chaals, care to chime in? Other comments on this matter? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Jonas Sicking wrote (on 4/21/09 6:22 PM): Hmm.. I tend to agree. Using an SQL database is only one possible solution that we should be examining. I would rather say that we should provide storage for structured data inside the UA. I'm not a fan of calling out neither SQL or name-value pair storage. At the same time I'm not sure that I care that much about it, as long as we can change the draft later in case the spec takes a different turn than the current drafts. / Jonas On Tue, Apr 21, 2009 at 2:44 PM, Nikunj Mehtanikunj.me...@oracle.com wrote: Apparently the new charter [1] that forces everyone to re-join the WG also lists among its deliverables as WebStorage with the explanation that WebStorage is two APIs for client-side data storage in Web applications: a name-value pair system, and a database system with a SQL frontend Clearly, if the WD of WebStorage has in its abstract something more general, the charter should not be so specific. I now understand that this new piece of text made its way into the charter recently. The last message I can see about charter change for WebApps [1] only talks about adding WebWorkers. Apparently other changes were also made, but no diff provided to members about the charter change proposal. Can you throw some light on this? Nikunj [1] http://www.w3.org/2009/04/webapps-charter [2] http://www.w3.org/mid/3e428ec7-1960-4ece-b403-827ba47fe...@nokia.comian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. Done.
Re: Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)
On Thu, 23 Apr 2009, Doug Schepers wrote: Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. If there is something that is more useful for Web authors as a whole than SQL, and if the browser vendors are willing to implement it, then the spec should use that, yes. (I don't know of anything that fits that criteria though. Most of the proposals so far have been things that are useful in specific scenarios, but aren't really generic solutions.) If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. The draft got published today, so it's too late to change the high-profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web Storage Scope and Charter
On Thu, 23 Apr 2009 22:18:40 +0200, Ian Hickson i...@hixie.ch wrote: The draft got published today, so it's too late to change the high-profile version of the spec. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. -- Anne van Kesteren http://annevankesteren.nl/
Re: Web Storage Scope and Charter
Hi, Ian- Ian Hickson wrote (on 4/23/09 4:18 PM): On Thu, 23 Apr 2009, Doug Schepers wrote: Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. If there is something that is more useful for Web authors as a whole than SQL, and if the browser vendors are willing to implement it, then the spec should use that, yes. (I don't know of anything that fits that criteria though. Most of the proposals so far have been things that are useful in specific scenarios, but aren't really generic solutions.) This seems to lead into a discussion of use cases and requirements. You don't include those in your draft... Do you have a UCR document that we could put on the wiki, like the one for Web Workers [1] (note that although I put that into the wiki, I pulled them from somewhere else, maybe the HTML wiki)? So, some of the requirements you're listing here are: * more useful for Web authors as a whole than SQL * browser vendors are willing to implement it * should have broad and scalable applicability The first two are rather hard to quantify, and part of the process of writing a spec is to discover what these are. The best solution is not necessarily the most obvious one from the start, and after deeper examination, browsers implementers may be willing to implement something that didn't appeal to them at the beginning. (Any spec is better than no spec, so the fact that they may be willing to implement whatever the current spec says doesn't mean it's the best solution.) What are the other criteria you have in mind? Which other solutions have you looked at that don't meet these criteria? If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. The draft got published today, so it's too late to change the high-profile version of the spec. It's not too late at all. This group can publish as frequently as it wants, and we could have another WD up next week, with such a message in it. That would have an equally high profile. The overhead of this seems much less than that of changing the charter. Rather than add this message, I'd like to just come to some sort of conclusion on the issue. What are the various proposals that exist to solve this problem other than SQL, and how willing are the browser vendors to implement those solutions? We can do both: publish an updated version of the spec that says we're looking at various solutions, and examine the solutions that come in (as a result of broad review that opens that door). If we are able to come to an immediate conclusion, I'm all in favor of that. But Nikunj, at least, doesn't seem to think we are there yet, so I think it's worth reopening the larger issue. [1] http://www.w3.org/2008/webapps/wiki/Web_Workers Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Web Storage Scope and Charter (was: CfC: FPWD of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers; deadline April 10)
Sounds good to me. On Thu, Apr 23, 2009 at 1:04 PM, Doug Schepers schep...@w3.org wrote: Hi, Folks- I discussed this a bit with Nikunj offline, in the context of the charter wording. He and I both agreed that the scope of the charter was too narrow (that was my fault; I changed the wording to reflect the abstract of the current Web Storage spec, and I probably shouldn't have), but we also agreed that the spec itself is higher profile and more important than the wording in the charter. Jonas and others seem to support broadening the scope, and I've also been reading various posts in the blogosphere that also question whether SQL is the right choice (I see a lot of support for JSON-based approaches). At the very least, I think this group should discuss this more before committing to any one solution. I note that Ian was already open to an early spec revision on the same lines, so I hope this isn't controversial. Rather than change the charter (which would require everyone who's already rejoined to re-rejoin at the simplest, and might require another AC review at the worst), Nikunj offered that he would be satisfied if more generic wording were put in the charter, and highlighted as an issue. I would propose something like, This specification currently contains wording specific to a SQL or name-value pair storage solution, but the WebApps WG is discussing other structured storage alternatives that may better match the use cases and requirements. I leave it up to Nikunj to provide wording that would satisfy him. If this is acceptable to the WG as a whole, I would ask that a message similar to the above be put in a prominent place in the spec. This seems like the soundest way forward. Art, Chaals, care to chime in? Other comments on this matter? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Jonas Sicking wrote (on 4/21/09 6:22 PM): Hmm.. I tend to agree. Using an SQL database is only one possible solution that we should be examining. I would rather say that we should provide storage for structured data inside the UA. I'm not a fan of calling out neither SQL or name-value pair storage. At the same time I'm not sure that I care that much about it, as long as we can change the draft later in case the spec takes a different turn than the current drafts. / Jonas On Tue, Apr 21, 2009 at 2:44 PM, Nikunj Mehtanikunj.me...@oracle.com wrote: Apparently the new charter [1] that forces everyone to re-join the WG also lists among its deliverables as WebStorage with the explanation that WebStorage is two APIs for client-side data storage in Web applications: a name-value pair system, and a database system with a SQL frontend Clearly, if the WD of WebStorage has in its abstract something more general, the charter should not be so specific. I now understand that this new piece of text made its way into the charter recently. The last message I can see about charter change for WebApps [1] only talks about adding WebWorkers. Apparently other changes were also made, but no diff provided to members about the charter change proposal. Can you throw some light on this? Nikunj [1] http://www.w3.org/2009/04/webapps-charter [2] http://www.w3.org/mid/3e428ec7-1960-4ece-b403-827ba47fe...@nokia.comian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. Done.
Re: Web Storage Scope and Charter
On Thu, 23 Apr 2009, Doug Schepers wrote: This seems to lead into a discussion of use cases and requirements. There's only one requirement that I know of: * Allow Web sites to store structured data on the client. There are many use cases, e.g. Google is interested in this to enable its applications to be taken offline. We recently released offline GMail using this SQL backend; one could easily imagine other applications like Calendar, Reader, DocsSpreadsheets, etc, supporting offline mode. A while back we released a demo of Reader using Gears' SQL database. But we would rather use a standard API than rely on Gears. So, some of the requirements you're listing here are: * more useful for Web authors as a whole than SQL At least as useful, not necessarily more useful. (SQL obviously wouldn't itself be a fit if it had to be more useful than SQL!) * browser vendors are willing to implement it * should have broad and scalable applicability These two seem like they apply to pretty much anything we do. Which other solutions have you looked at that don't meet these criteria? Straight structured storage (e.g. a JSON object), the DOM, Atom-based storage mechanisms, Lucene (better than SQL for full text search, not so good for anything else), CouchDB (better for hetreogeneous data sets, not so good for homogeneous data, e.g. a mail folder), various others. The draft got published today, so it's too late to change the high-profile version of the spec. It's not too late at all. This group can publish as frequently as it wants, and we could have another WD up next week, with such a message in it. Fair enough. I've added a message. If we are able to come to an immediate conclusion, I'm all in favor of that. But Nikunj, at least, doesn't seem to think we are there yet, so I think it's worth reopening the larger issue. Given that implementations are shipping and high-profile Web pages are actively using these features today, we really should come to a decision sooner rather than later, or it'll become a moot point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
