Re: Regarding: Making the W3C Web SQL Database Specification Active
Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ count as an independent implementation of the SQLite SQL syntax? Regards- Shane Harrelson On Tue, Oct 1, 2013 at 8:53 AM, Arthur Barstow art.bars...@nokia.comwrote: On 10/1/13 8:46 AM, ext David Bruant wrote: Le 27/09/2013 23:23, Jonas Sicking a écrit : On Wed, Sep 25, 2013 at 3:39 PM, Michael Fitchett michael.fitch...@spotsync.com wrote: Dear Members of the W3C Consortium:: Regarding: Making the W3C Web SQL Database Specification Active I would like to request that you make the W3C Web SQL Database specification active again. The Web SQL Database Specification enables developers to build web-based applications that can store, retrieve, manipulate and query against data on the client machine. This technology is similar to SQLite, Microsoft SQL Server, MySQL, etc. Web SQL combined with Manifest enable developers to build web-based applications that work while offline. The Web SQL Database specification was on the W3C Recommendation track, but the specification was stopped because Mozilla and Microsoft did not want to implement a specification that lacked proper SQL definition. I know there is a need for both a NoSQL and SQL solution. The two specifications (Web SQL Database and Indexed Database API) that exist to date are acceptable.. However, as stated above, the problem is the lack of definition for SQL. Since lack of definition is the issue, I would like to recommend a remedy. I know SQL experts and great documentation writers who I would gladly hire to further define the Web SQL Database specification and fill in the missing SQL definition. Is this something that would be possible to help revive the specification and get the remaining vendors on board? The minimum requirements for bringing back WebSQL, or any other SQL-based web spec is IMHO: 1. A specification for the SQL dialect being proposed. 2. *Two* independent, production quality, database implementations being willing to implement exactly that SQL dialect. Not a subset of it, and not a superset of it. 3. The two independent implementations need to have roughly the same performance characteristics. I.e. it's not ok for an implementation to generate correct results, but do it so slowly that it's in practice unusable. I'd like to add another requirement which is having a significant advantage over IndexedDB. If web devs want SQL, they can have it on top of IndexedDB in the form of an open source library (I'm willing to be it already exists). They don't need to wait for a standard to emerge, nor for browsers to consistently implement it. If they really want a spec, they can create a W3C community group (or a Github repo). We don't need browsers to do all the work for us! Michael - I don't see consensus to re-visit WebApps' decision to stop working on Web SQL Database. Like David, I also was thinking that a W3C Community Group could be a way for you to do related work. -Regards, AB
Re: Regarding: Making the W3C Web SQL Database Specification Active
Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ count as an independent implementation of the SQLite SQL syntax? I don't understand: is it a port of SQLite to managed code, or is it a reimplementation from scratch? -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Regarding: Making the W3C Web SQL Database Specification Active
On Tuesday, December 31, 2013 at 3:29 AM, Shane Harrelson wrote: Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ count as an independent implementation of the SQLite SQL syntax? Using an unmaintained project as a ways of advancing as specification would kinda defeat the point of standardization of browser technology. To benefit the web, the only independent implementations that would actually matter would need to be browser-based. So no, it would not count (not unless we want to really dilute how a specification becomes a W3C standard). -- Marcos Caceres
[Bug 24184] New: References undefined type EventHandler
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24184 Bug ID: 24184 Summary: References undefined type EventHandler Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: gl...@skynav.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The definition of interface WebSocket refers four times to the undefined type EventHandler. The specification must include a definition or a reference to a definition of EventHandler. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Regarding: Making the W3C Web SQL Database Specification Active
On Wed, 01 Jan 2014 23:00:21 +0100, Marcos Caceres w...@marcosc.com wrote: On Tuesday, December 31, 2013 at 3:29 AM, Shane Harrelson wrote: Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ count as an independent implementation of the SQLite SQL syntax? So no, it would not count (not unless we want to really dilute how a specification becomes a W3C standard). To prove that it is possible to independently implement the specification and get something interoperable, it would in principle be fine. But that is only one part of the requirements for a standard... Using an unmaintained project as a ways of advancing as specification would kinda defeat the point of standardization of browser technology. In that it fails to change the perception that there is not real interest in making the particular spec into a standard. To benefit the web, the only independent implementations that would actually matter would need to be browser-based. That's not really true. It is important to get implementations in browsers, and the fact that currently a number of major browsers have stated that they are not interested in implementing (or in some cases in maintaining impementations of) Web SQL is one reason it is not considered worth further work at this time. If there were compelling* services based on WebSQL, the question might be re-examined. The inability to meet a particular bureaucratic interpretation of independently implemented interoperable uses isn't the reason why work has stopped. It happened because there was no apparent likelihood of WebSQL becoming a standard that was generally implemented, and there was an alternative that appeared to have a much higher probability of being worth working on. Of course, all these judgements are just that. History has proven them wrong in the past, and that will continue to happen. cheers Chaals *I mean something that has 10% penetration, or 25% penetration in a few key markets, not just a few hundred people agree this is really fantastic - although if those people happen to be browser engineers or standards wonks the reality is that you have a better chance of getting a real standard to occur) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
