- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 23 Apr 2009 14:34:30 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: Nikunj Mehta <nikunj.mehta@oracle.com>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, Charles McCathieNevile <chaals@opera.com>, "Michael(tm) Smith" <mike@w3.org>
Sounds good to me. On Thu, Apr 23, 2009 at 1:04 PM, Doug Schepers <schepers@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 Mehta<nikunj.mehta@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-827BA47FE1EB@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. > >
Received on Thursday, 23 April 2009 21:35:26 UTC