W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: What do we mean by "parking" Web Database? [Was: Re: TPAC report day 2]

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Mon, 9 Nov 2009 14:29:53 -0800
To: Maciej Stachowiak <mjs@apple.com>
Message-Id: <C4028937-7999-4FE5-86B0-368A9E7E22F1@oracle.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <art.barstow@nokia.com>, Charles McCathieNevile <chaals@opera.com>, public-webapps <public-webapps@w3.org>

On Nov 9, 2009, at 12:58 AM, Maciej Stachowiak wrote:

>>> 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.
>> I definitely agree that we don't want a solution that punishes the
>> mobile market. I think the way to do that is to ensure that SimpleDB
>> is useful even for mobile platforms.
> I don't think SimpleDB is useless for mobile platforms. You  
> certainly *could* use it. But it does have three significant  
> downsides compared to the SQL database: (1) it's very different from  
> what developers have already (happily) been using on mobile;

Mobile and iPhone developers are among the quickest to adopt new  
technologies, if I am not mistaken.

> (2) the target design point is that it's primarily expected to be  
> used through JavaScript libraries layered on top, and not directly  
> (so you have to ship more code over the wire); and

WebSimpleDB will always remain easy and good to use directly, even  
though it will also support those who want to use libraries on top.  
Whether people would still prefer to use libraries or not, will depend  
on their use case. Specific use cases would help to find a more  
objective solution to your issue.

> (3) for more complex queries, more of the work has to be done in  
> JavaScript instead of in the database engine (so performance will  
> likely be poor on low-power CPUs).

Those applications doing simple boolean index expression evaluation  
could get better performance from WebSimpleDB than with SQLite because  
of the overhead of parsing SQL, generating query plans, and optimizing  
them without knowledge of index selectivity. Knowing the  
sophistication of the average Web developer, such applications may  
dominate the total set of queries run in implementations.

> For these reasons, I expect a lot of mobile developers will stick  
> with the SQL database, even if we also provide something else.
> If you have ideas for how to improve SimpeDB on these dimensions,  
> I'd be glad to hear it. But I'm not sure it's really possible to  
> address them without significantly changing the design direction of  
> SimpleDB, so I'm not really expecting they will be solved.

Could you help us find the use cases that explain what problems users  
are likely to face with WebSimpleDB? If so, we could adjust the design  
to better support them.

Received on Monday, 9 November 2009 22:33:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC