On Nov 8, 2009, at 12:43 PM, Jonas Sicking wrote:
On Sun, Nov 8, 2009 at 7:24 AM, Arthur Barstow
<[email protected]> wrote:
On Nov 7, 2009, at 3:53 PM, ext Charles McCathieNevile wrote:
The draft minutes are included at
http://www.w3.org/2009/11/02-webapps-minutes.html starting from
the WebIDL
Thanks for the summaries Chaals!
Offline storage / databases
The SQL-based Web Database proposal will probably not be
implemented by
major players so is being shifted to a "parked and of historical
interest"
mode while we work on the Web Simple Database proposal from
Nikunj. We
also touched on Datacache, and ended with an action for Nikunj to
explain
how it relates to appcache if you have the two running together.
The minutes for the Web Database discussion [1] don't address what
we mean
by "parking" Web Database.
I heard Hixie say it should be included in a call for pre-LC
comments thus I
included it in the related call on 4 November [2] and members of
the group
have an opportunity to raise issues if they think Web Database is
not ready
for a LCWD.
However, later in the week, I participated in some hallway
discussions where
members of the group said they prefer Web Database be "parked" by
publishing
it as a Working Group Note (rather than a LCWD):
[[
http://www.w3.org/2005/10/Process-20051014/tr.html#q75
Working Group Note
A Working Group Note is published by a chartered Working Group to
indicate
that work has ended on a particular topic. A Working Group MAY
publish a
Working Group Note with or without its prior publication as a
Working Draft.
]]
So, when we say we want to "park" Web Database, what do we mean:
publish as
LCWD, publish as Working Group note, something else? If necessary,
we can
start a CfC on this question.
Representing one of the implementors of this spec, I'd prefer that we
proceed to LCWD instead of publishing as a Note. With multiple
implementations likely, it seems better to have the full W3C review
process, and to have a test suite developed, etc. W3C has published
many specifications that are supported by 0/5 browsers, so I don't
think 3/5 support would be a reason to stop the standards process.
-Regards, Art Barstow
[1] http://www.w3.org/2009/11/02-webapps-minutes.html#item12
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0477.html
From a technical point of view, are we expecting that there will
actually be multiple independent interoperable implementations? If
Operas implementations uses SQLite in the backend, it seems like all
implementations are SQLite based and thus technically not independent.
It should be noted that many aspects of the spec must be implemented
independently even if SQLite is the underlying storage back end.
The reason I bring this aspect up is that this was one of the big
reasons that we didn't want to implement this at mozilla, that it
seemed to lock us in to a specific backend-library, and likely a
specific version of that library.
We actually have a bit of a chicken-and-egg problem here. Hixie has
said before he's willing to fully spec the SQL dialect used by Web
Database. But since Mozilla categorically refuses to implement the
spec (apparently regardless of whether the SQL dialect is specified),
he doesn't want to put in the work since it would be a comparatively
poor use of time. If Mozilla's refusal to implement is only
conditional, then perhaps that could change.
At the face-to-face, Mozilla representatives said that most if not all
of the developers they spoke to said they wanted "anything but SQL" in
a storage solution. This clashes with our experience at Apple, where
we have been shipping Web Database for nearly two years now, and where
we have seen a number of actual Web applications deployed using it
(mostly targeting iPhone). Our developers, who actually used the SQL-
based solution rather than just considering what it might be like,
were all very happy with it. We received various points of feedback
about our solutions for offline Web Apps in general, but to my
knowledge not one developer said SQL was a problem for them in practice.
It seems pretty clear to me that, even if we provide Web SimpleDB as
an alternative, our mobile-focused developers will continue to use the
SQL database. First, they will not see a compelling reason to change.
Second, SimpleDB seems to require more code to perform even simple
tasks (comparing the parallel examples in the two specs) and seems to
be designed to require a JS library to be layered on top to work well.
For our mobile developers, total code size is at a premium. They seem
less willing than desktop-focused Web developers to ship large JS
libraries, and have typically used mobile-specific JS libraries or
aggressively pruned versions of full JS libraries.
In light of this divergent feedback, would Mozilla consider the SQL-
based Web Database as a future implementation possibility in addition
to SimpleDB, if the SQL dialect were to be fully specified? Would
Hixie consider specifying the SQL dialect if lack of spec turns out to
be Mozilla's sole reason to refuse to implement?
I think the likely outcome of the current situation will be that new
mobile browsers will have a harder time establishing themselves in the
market, since many popular mobile web apps will be using a database
technology where the query language is not fully specified. That would
be an unfortunate outcome.
Ultimately I don't care much either way really. Though it would be
nice to make it clear that it's not expected that the spec will be
implemented in all browsers.
I think it's up to browser implementors to make clear what their plans
are, to the degree they choose to do so.
Regards,
Maciej
