On Dec 9, 2007 1:29 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
I like the new Database API design a lot, but I wish there was an
option for synchronous DB access.
I did some quick tests and I can insert 1000 rows, totaling 3KB+ of
data into SQLite in less than a tenth of a second on Windows
On Dec 15, 2007 5:36 PM, Benjamin West [EMAIL PROTECTED] wrote:
It's unclear how this might affect developers using the offline API.
Ben West
Thought I'd add that for many developers, the issues with asynchronous
APIs requiring callbacks are difficult to overcome. The examples
shown so far
On Dec 15, 2007, at 6:00 PM, Benjamin West wrote:
I suspect that for most typical uses on most typical runtimes, most
developers would choose to risk the performance hit of synchronous
access to the complexity of binding methods to their objects. I
suspect this allows faster prototyping
2007/12/11, Krzysztof Żelechowski:
Allowing the script to wait until the transaction completes would be
enough to provide synchronization, wouldn't it? A stubborn programmer
can still do it: make a transaction set an event upon completion and
make the script loop until that event is set.
Dnia 11-12-2007, Wt o godzinie 11:22 -0800, Aaron Boodman pisze:
With an asynchronous API, it gets quite a bit messier. Here's an
example of what it might look like:
var messages = incoming_data;
db.transaction(function(tx) {
processNextMessage(tx);
});
function
I think the issue you're forgetting is when opening a transaction can
fail. The transaction callback is only called when the transaction is
successfully opened and you know that it is starting out valid.
~Brady
On Dec 12, 2007, at 9:37 AM, Dimitri Glazkov wrote:
.. Speaking of batches,
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx
Can you help me understand the problem you're pointing out? The
difference between the idea outlined and the current spec is the
absence of the transaction callback, but it basically (I think) has
the equivalent net effect.
db.createTransaction is just a mutable list of statements until the
On Dec 12, 2007, at 11:18 AM, Dimitri Glazkov wrote:
Can you help me understand the problem you're pointing out? The
difference between the idea outlined and the current spec is the
absence of the transaction callback, but it basically (I think) has
the equivalent net effect.
In the current
Dnia 10-12-2007, Pn o godzinie 21:22 -0600, Dimitri Glazkov pisze:
Guys, I think the point was that it's not unreasonable to have
synchronous API. The argument about slow/busy devices is valid, but I
still think the developer should have the choice of either going with
a simple query/receive
Dnia 10-12-2007, Pn o godzinie 16:04 -0800, Dan Mosedale pisze:
On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote:
I'd hate for GMail to mysteriously stop working every couple of
days just because of some background process that I had no
knowledge of. As a developer, how would you
On Dec 11, 2007, at 11:22 AM, Aaron Boodman wrote:
How does the globalStorage implementation deal with this problem? It
has a synchronous storage API. True it is probably designed for
smaller amounts of data, but there's nothing preventing an author from
using it for large amounts (is there?).
On Dec 11, 2007 11:22 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
Or does
globalStorage not guarantee that data is written when the setter
returns?
A thing I've been thinking about for Gears would be the ability to
spin up an in-memory/async session database, with the sense of
session being the
On Dec 11, 2007, at 11:40 AM, Aaron Boodman wrote:
I thought it would be useful if the spec had a simple synchronous API
for cases where the developer expects operations to happen quickly
and/or doesn't care if they timeout ocassionally (because, for
example, the application will retry
It's clear that most people here feel passionately that this is the
wrong thing to do. Perhaps it's best that we table this until
something like workerpools are in the spec.
Worker pools do not resolve the problem, even if you were to force
any synchronous IO to be performed on a worker
On Dec 11, 2007, at 3:02 PM, Oliver Hunt wrote:
It's clear that most people here feel passionately that this is the
wrong thing to do. Perhaps it's best that we table this until
something like workerpools are in the spec.
Worker pools do not resolve the problem, even if you were to force
16 matches
Mail list logo
