It is envisaged that html5 will have better options for local storage than
just cookies. Actually, the browser will offer access to a (local) SQL
database using an asynchroneous javascript API. The javascript API seems
defined, but the minimal required SQL support is not (just a reference to
SQLite 3.6, as a stub).

I guess someone could do a cross section of the SQL offered by SQLite and
SQL offered by Firebird and propose that as the required SQL support.
Probably someone else will then do a cross section with Postgres' SQL and
thus arrive a smaller SQL subset again. As usual, the issues will not be so
much around the core SQL statements, but around the built-in functions, the
security model, type conversion, etc.

However, there are reasons many browser builders have chosen to include
SQLite so far. In my opinion:
- public domain source code, patent-issue free as well
- incredibly small (<0.5MB with all options compiled in, such as full text
search)
- fast
What can Firebird offer to browser builders that will make them include
the FB option? Security? C/S operation? At the same time there seems to be
push back from the no-sql community, whishing to see no sql at all in a web
standard.

Paul


On Thu, 05 Aug 2010 09:48:19 -0300, Adriano dos Santos Fernandes
<adrianosf@...> wrote:

> On 05/08/2010 09:26, marius adrian popa wrote:
>> On Thu, Aug 5, 2010 at 3:16 PM, Adriano dos Santos Fernandes<
>> adrianosf@...> wrote:
>>
>>>
>>> On 05/08/2010 09:09, marius adrian popa wrote:
>>>> Can we help with another implementation like firebird for example (or
>>>> close to the sql standard)
>>>> and fix this spec error
>>>>
>>>> http://dev.w3.org/html5/webdatabase/
>>>>
>>>> I guess it's easy to use from wekit-qt the sql classes to access an
>>>> embedded firebird
>>>>
>>>> http://trac.webkit.org/wiki/QtWebKit
>>>> http://www.codeproject.com/KB/database/qt-and-firebird-start.aspx
>>> They want new implementation but say "User agents must implement the

SQL

>>> dialect supported by Sqlite 3.6.19".