On 4/10/09 1:53 PM, Maciej Stachowiak wrote:
I don't think this one point should be decisive by itself. But I don't
think it should be given zero weight either. I do think the existence of
an implementation of the current spec and Web content using it somewhat
raises the burden of proof on anyone proposing a redesign.
I'm not so sure of the usefulness of that argument. Just because
company X implements and proposes feature Y, and convinces company Z to
implement it on their site, it doesn't somehow get extra credibility
(strictly a hypothetical situation). If there are serious issues with
the proposal, they should be looked at and not glossed over. For what
I've seen of this discussion, serious issues that are being raised are
being glossed over or being dismissed as essentially "not our problem".
Note that one of the clients in question is the offline-enabled mobile
version of GMail. I think this demonstrates that the SQL-based Database
Storage can serve the needs of an advanced and polished Web application.
In addition, we have a rough demonstration that it is practically
implementable in a modern Web engine.
Just because an API serves the needs of an advanced and polished web
application doesn't mean it's the right API. We could let web authors
write some form of assembly to do task X, and they could make it serve
their needs, but it most certainly would not be the right API. An
exaggeration, sure, but this is an API we are going to have to live with
for a long time. We should take care to ensure that it's the right API
for the web.
My biggest problem with this draft is that I still don't see an answer
for why SQL was chosen, especially given the drawbacks that have already
been highlighted.
Cheers,
Shawn
begin:vcard
fn:Shawn Wilsher
n:Wilsher;Shawn
email;internet:[email protected]
title:Platform Engineer
version:2.1
end:vcard
