Re: [IndexedDB] Soliciting feedback from SQL Vendors

On Mon, Oct 10, 2011 at 4:47 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 10/10/2011 1:44 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchard<chuck@jumis.com>
>>  wrote:
>>>
>>> Is there interest or presence on this list from major SQL vendor
>>> developers
>>> such as PostgreSQL and MySQL?
>>
>> I'd love to get input from SQL database developers! I don't have any
>> particularly great ideas for how to get that input other than simply
>> mailing the various mailing lists directly.
>
> I'll go ahead with that. The first time around, I was asked about the
> security / quota model.
> I'd prefer to just say that it's "out of scope", though there are proposals.
> I see no reason to derail things on that issue.

I think it's currently somewhat undefined.

Firefox currently guarantees that any data written will be written
"permanently". I.e. it won't be deleted other than through system
malfunction (computer being run over by a steam roller) or explicit
user action (user choosing to delete all stored data for a given
site). Because the data is stored permanently we ask the user before
doing so.

I *believe* chrome more works like a cache. I.e. if the user ends up
with more than X bytes of total data, the least recently used data is
removed. I don't know the exact granularity of the data being removed
(whole database at a time, or whole origin at a time).

> Many vendors are working with low-level languages running in machine code:
> is there a quick hack/means
> to describing the event loop model? Should I sheepishly leave that part out?

The wording in the spec is somewhat inconsistent right now. But it
does attempt to explicitly describe what happens in separate
asynchronous tasks, and what happens synchronously on the calling
thread.

If something is unclear in the spec, please file a bug.

> Most of these developers are working with simple sync/async libraries that
> are called from C and C++.
>
> The event loop is fundamental to some behaviors; it's assumed in the
> specification. But, it's not something I really want to get hung-up on.
> Ideas for how to avert that? Is it unethical to simply not bring it up?

Please do bring it up. The sync vs. async behavior is very important.
A lot of effort has gone into making the API usable by keeping as much
as possible synchronous, while still keeping any IO operations async.

> Is it something that they're going to have to figure out on their own? Such
> as with an "endloop" private extended function.

I don't know what you mean by this.

/ Jonas

Received on Tuesday, 11 October 2011 01:43:51 UTC