Re: Web Storage & SQL

On Tue, Apr 14, 2009 at 9:08 AM, Nikunj Mehta <nikunj.mehta@oracle.com> wrote:
>
> On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote:
>
>> On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta <nikunj.mehta@oracle.com>
>> wrote:
>>>
>>> On Apr 10, 2009, at 3:13 PM, Ian Hickson wrote:
>>>>
>>>> On Fri, 10 Apr 2009, Nikunj Mehta wrote:
>>>>>
>>>>> Can someone state the various requirements for Web Storage? I did not
>>>>> find them enunciated anywhere.
>>>>
>>>> There's only one requirement that I know of:
>>>> * Allow Web sites to store structured data on the client.
>>>> There are many use cases, e.g. Google is interested in this to enable
>>>> its
>>>> applications to be taken offline. We recently released offline GMail
>>>> using
>>>> this SQL backend; one could easily imagine other applications like
>>>> Calendar, Reader, Docs&Spreadsheets, etc, supporting offline mode. A
>>>> while
>>>> back we released a demo of Reader using Gears' SQL database.
>>>
>>> Last time I tried this trick I was asked to come back with more precise
>>> use
>>> cases [1]. Then I put together more detailed use cases [2], and even
>>> those
>>> were not considered to be written precisely enough. So it looks like the
>>> bar
>>> for what constitutes a use case or requirement seems to be quite high.
>>
>>> [1]
>>> http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0079.html
>>> [2]
>>> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html
>>
>> As far as I am concerned the use cases you enumerate in [2] were fine.
>> However note that even the current WebStorage API makes it possible to
>> address those use cases. Just in a way that is vastly different than
>> the solution that you propose in [2].
>>
>> Do you not agree?
>
> WebStorage does not, or for that matter any other speced API, make it
> possible to intercept PUT/POST/DELETE requests to perform offline behavior
> that can be later synchronized to the server.

Indeed. But it does make it technically possible to address the use
cases that you listed.


>> I think the main road block to accepting something like that is simply
>> needing more experience in the WG. Since your requirement, or at least
>> your proposed solution, require that the standard design how the
>> synchronization should work, I personally would like to know more
>> about other synchronization technologies before accepting your
>> proposal.
>
> I have been working to simplify the requirements to allow
> application-specified synchronization provided:
>
> 1. The browser stores/caches certain URLs à la Gears LocalServer and the
> browser responds to GET/HEAD requests for those URLs
> 2. The browser allows JS interception of requests for non-GET/HEAD requests
> to certain URLs
> 3. The browser enforces cookie requirements for accessing those URLs
> 4. The browser provides some structured storage JS API for storing
> synchronization state (not the contents of the data itself)
> 5. The browser provides JS to contribute content to the browser store/cache
> as text (or blob)

So it's entirely the responsibility of JS to synchronize the data?
Using whatever means already exist, such as XHR etc? Nothing tied to
AtomPub at all?

>> So it has nothing to do with lack of use cases, much more to do with
>> that we're designing a different very API, and so we need different
>> expertise and background data.
>
> At this point, the API that is required for BITSY is far simpler than it
> used to be - you can just think of it as a couple of extra methods to the
> Gears LocalServer API. That means we have a fair amount of expertise within
> this WG - both Google and Oracle have toyed with slightly different parts of
> this problem. Oracle has implemented the browser mechanisms above as a
> plug-in for both Safari and Firefox.
>
> Oracle can provide this specification as a member submission if that helps
> the WG.

Of course in order to be able to evaluate a proposal we have to see it :)

>>>> But we would rather use a standard API than rely on Gears.
>>>
>>> I think if we are serious about building a good foundation for local
>>> persistence, then we should have more precise requirements for Web
>>> Storage.
>>> Otherwise, we risk prematurely standardizing some dialect of SQL
>>> supported
>>> by SQLite as "Web Storage".
>>
>> Not sure if it makes a difference, but I would be very surprised if we
>> ended up with the same SQL dialect as what SQLite uses. I haven't
>> worked with SQLite personally, but from what I understand it uses some
>> extensions that doesn't exist in many other database engines. It's
>> important to me that we don't lock ourselves into any particular
>> database and so we should restrict ourselves to a dialect that is
>> widely supported. So for example if you couldn't use an Oracle DB as a
>> backend I would be very disappointed.
>>
>>> Here's a compilation of requirements from what I have read in this thread
>>> and other work I have done in this area:
>>
>>> queries may involve full-text search, parameterized or query by example
>>> search, or a combination
>>
>> What do you mean by "query by example"?
>
> From [1] and [2], QBE is a mechanism to create a query based on examples
> provided by a user searching data. Microsoft Access and Siebel CRM both have
> given QBE access to their users for long and it avoids having the user
> specify detailed SQL queries.

This does not really explain to me what QBE is. What is the use case
you are trying to solve, and how does QBE help solve it?

>>> queries permit user defined functions
>>
>> Why?
>
> UDFs enable specialized processing of application data in a language that is
> easily understood by the application designer.

I know what UDF is, I think, but I still don't know why you need them.
Again, what is the use case you are trying to solve, and how does UDF
help solve it?

I'm also confused by the discussions about querying databases. I
thought your proposal was basically a local http server that used
callbacks into webpage javascript at various points? Where does a
database enter the picture?

/ Jonas

Received on Friday, 17 April 2009 21:40:18 UTC