Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Wed, 12 Aug 2009, Aaron Boodman wrote:
I also don't see what not having a callback buys. I'm not sure if you
noticed, but I was suggesting that the callback be reentrant. So if you
do this:
var theResult = null;
database.syncTransaction(function(tx) {
theResult = tx.executeSQL(select * from ...).rows[0].val;
});
alert(theResult);
It will do the right thing. Are you concerned that developers won't
realize that the callback is reentrant and will invest more effort
writing their code in an asynchronous style?
The only reason for not using callbacks in the sync API was that callbacks
are harder to work with than the straight-forward imperative style.
I can change the spec to a hybrid style with statements in the imperative
form but the transactions themselves using closures. Would that be ok?
Yes, that is what I was proposing.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, 3 Aug 2009, Aaron Boodman wrote:
The API was intentionally made more obviously synchronous to avoid
having to make people use callbacks.
Would making all transactions automatically rollback if not committed
when the event loop spins be an acceptable substitute solution?
A few problems with this:
- In the case of workers, it could be more common for a single event
loop entry to last a very long time. So closing the transaction on event
loop exit could effectively mean never.
I don't think reentrant callbacks really get around that much, though
maybe they make it a little more obvious.
- It is likely to lead to difficult to debug issues. In the common path,
developers will close transactions because they will notice incorrect
code during development. It is only in the error cases that they will
forget to close the transactions. So every so often, you'll get errors
or hung workers (depending on what the behavior is spec'd to be when you
open a sync transaction while another is open in the same worker), and
no good way to track down the transaction that was left open. In my
experience with Gears, to avoid these issues, the very first thing
developers did was write a wrapper around the Gears API that worked the
way I'm suggesting.
Fair enough.
I also don't see what not having a callback buys. I'm not sure if you
noticed, but I was suggesting that the callback be reentrant. So if you
do this:
var theResult = null;
database.syncTransaction(function(tx) {
theResult = tx.executeSQL(select * from ...).rows[0].val;
});
alert(theResult);
It will do the right thing. Are you concerned that developers won't
realize that the callback is reentrant and will invest more effort
writing their code in an asynchronous style?
The only reason for not using callbacks in the sync API was that callbacks
are harder to work with than the straight-forward imperative style.
I can change the spec to a hybrid style with statements in the imperative
form but the transactions themselves using closures. Would that be ok?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Wed, Aug 12, 2009 at 4:33 PM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 3 Aug 2009, Aaron Boodman wrote:
The API was intentionally made more obviously synchronous to avoid
having to make people use callbacks.
Would making all transactions automatically rollback if not committed
when the event loop spins be an acceptable substitute solution?
A few problems with this:
- In the case of workers, it could be more common for a single event
loop entry to last a very long time. So closing the transaction on event
loop exit could effectively mean never.
I don't think reentrant callbacks really get around that much, though
maybe they make it a little more obvious.
My point was just that using a closure eliminates the case where a
transaction gets left open because of buggy code. It eliminates the
problem where a transaction should have been closed, but wasn't.
You're right that it does nothing for an infinite loop inside a
transaction. Nothing will save us from that.
I also don't see what not having a callback buys. I'm not sure if you
noticed, but I was suggesting that the callback be reentrant. So if you
do this:
var theResult = null;
database.syncTransaction(function(tx) {
theResult = tx.executeSQL(select * from ...).rows[0].val;
});
alert(theResult);
It will do the right thing. Are you concerned that developers won't
realize that the callback is reentrant and will invest more effort
writing their code in an asynchronous style?
The only reason for not using callbacks in the sync API was that callbacks
are harder to work with than the straight-forward imperative style.
I can change the spec to a hybrid style with statements in the imperative
form but the transactions themselves using closures. Would that be ok?
Yes, that is what I was proposing.
- a
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, 27 Jul 2009, Aaron Boodman wrote:
On the subject of the callbacks, you should note that only having the
sync API in workers won't fix this. The callbacks are a natural result
of the requirement to never leave transactions open.
The current sync proposal's explicit commit/rollback methods are a
bug, not a feature. They should be changed, so that the usage is along
the lines of:
database.syncTransaction(function(tx) { // This callback is
re-entrant for JS point of view
var result = database.executeSQL(statement, args); // executeSQL is
synchronous rather than async inside sync transactions
});
So it would get rid of the statement callbacks, but not the transaction one.
The API was intentionally made more obviously synchronous to avoid having
to make people use callbacks.
Would making all transactions automatically rollback if not committed when
the event loop spins be an acceptable substitute solution?
On Fri, 24 Jul 2009, Nikunj R. Mehta wrote:
It appears that Database, SQLTransactionCallback,
SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction,
SQLStatementCallback, and SQLStatementErrorCallback interfaces can all
be eliminated from WebDatabase completely.
Given WebWorkers and DatabaseSync, why do we need the Database object at
all? Are there use cases that cannot be satisfied by the combination of
the two that?
There is a brand new programming model being promoted by the Database
object, it is as complex as it gets and seriously I cannot get it. I
don't know about you, but I doubt it will work for an average Web page
author. Given its programming model, Oracle is not supportive of the
asynchronous Database and related interfaces.
Since the only way to communicate with workers is asynchronously, it
doesn't seem to help authors much if we require that they put all their
database calls on worker threads.
On Mon, 27 Jul 2009, Nikunj R. Mehta wrote:
This is certainly foreign to most database developers.
This API isn't intended for database developers. It's intended for
front-end HTML developers.
On Mon, 27 Jul 2009, Nikunj R. Mehta wrote:
On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote:
I think this is an important invariant, because otherwise script
writers _will_ shoot themselves in the foot. These aren't professional
database developers; Web authors span the gamut of developer
experience from the novice who is writing code more by luck than by
knowledge all the way to the UI designer who wound up stuck with the
task for writing the UI logic but has no professional background in
programing, let alone concurrency in databases. We can't be firing
unexpected exceptions when their users happen to open two tabs to the
same application at the same time, leaving data unsaved.
The above text referred to a certain class of developers as being unable
to cope with unexpected exceptions. Most Web authors are not experts
at parsing specifications, I think you will agree. Database developers
exist as a class. Most database developers are not UI programmers, I
think you will agree. We all make generalizations and they are useful to
a certain extent. They help us do language design, and I feel that one
should identify the classes of developers and their
readiness/preferences.
The point is that database development is not new. There are already
programming models available that people rely on for using applications
in developing database-based applications. Why introduce yet another
one? Just because someone proposed it and no one was interested in
proposing another one? And we are talking here of standardizing one that
is duplicating what can be achieved though JavaScript and much simpler,
more conventional programming model.
I don't really understand your objection. What is the problem with the
async database API?
[Aaron wrote:]
What I can say is that given the requirements, this is the only
interface I can imagine that works. I can also note that as a web
developer, I didn't find this interface foreign. It is a bit
unfortunate in the callbackyness, but I think it is a good tradeoff to
be able to use databases without a worker.
This design also has the advantage of having implementations in webkit
and chromium so we at least know that it is implementable.
Anything that is Turing complete, can be implemented. So what? Since
when did the bar get lowered so much that only an existence proof is
required?
Actually the bar was raised to at least that high. It was lower before. :-)
On Mon, 27 Jul 2009, Jonas Sicking wrote:
Designing APIs for the web is different from designing APIs for many
other platforms. The fact that the resulting API comes out differently
than elsewhere is not I think we can avoid.
Indeed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/,
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Aug 3, 2009 at 3:36 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 27 Jul 2009, Aaron Boodman wrote:
On the subject of the callbacks, you should note that only having the
sync API in workers won't fix this. The callbacks are a natural result
of the requirement to never leave transactions open.
The current sync proposal's explicit commit/rollback methods are a
bug, not a feature. They should be changed, so that the usage is along
the lines of:
database.syncTransaction(function(tx) { // This callback is
re-entrant for JS point of view
var result = database.executeSQL(statement, args); // executeSQL is
synchronous rather than async inside sync transactions
});
So it would get rid of the statement callbacks, but not the transaction one.
The API was intentionally made more obviously synchronous to avoid having
to make people use callbacks.
Would making all transactions automatically rollback if not committed when
the event loop spins be an acceptable substitute solution?
A few problems with this:
- In the case of workers, it could be more common for a single event
loop entry to last a very long time. So closing the transaction on
event loop exit could effectively mean never.
- It is likely to lead to difficult to debug issues. In the common
path, developers will close transactions because they will notice
incorrect code during development. It is only in the error cases that
they will forget to close the transactions. So every so often, you'll
get errors or hung workers (depending on what the behavior is spec'd
to be when you open a sync transaction while another is open in the
same worker), and no good way to track down the transaction that was
left open. In my experience with Gears, to avoid these issues, the
very first thing developers did was write a wrapper around the Gears
API that worked the way I'm suggesting.
I also don't see what not having a callback buys. I'm not sure if you
noticed, but I was suggesting that the callback be reentrant. So if
you do this:
var theResult = null;
database.syncTransaction(function(tx) {
theResult = tx.executeSQL(select * from ...).rows[0].val;
});
alert(theResult);
It will do the right thing. Are you concerned that developers won't
realize that the callback is reentrant and will invest more effort
writing their code in an asynchronous style?
- a
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: It appears that Database, SQLTransactionCallback, SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction, SQLStatementCallback, and SQLStatementErrorCallback interfaces can all be eliminated from WebDatabase completely. Given WebWorkers and DatabaseSync, why do we need the Database object at all? Are there use cases that cannot be satisfied by the combination of the two that? All use cases are implementable with workers + synchronous databases given enough effort. This is really good to know. This likely means that the WG would be required to find strong reasons to keep the duplication. But using workers is a large burden: they are completely separate JavaScript environments that share nothing with the main web page. Having to use that for simpler use cases would be very unfortunate. I am not sure how large a burden this is. Can you quantify it? Can you explain why this would be unacceptable? If all we had was synchronous databases and you could only use them from workers, I think you'd immediately start seeing developers create JavaScript wrappers that look a lot like our current Database interface, because... If there is a good chance for a JavaScript library to thrive in this environment, then there is all the more reason for the WG to not bake in a required browser interface. There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. 3. the only supported model of transaction isolation is serialization of all database access. This is certainly foreign to most database developers. Editors and/or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. Also, the programming model is not that novel. It is a straightforward application of IOC to ensure that transactions are always closed. Aaron misunderstands me here as I have no objection, per se, to IOC or RAII. The problem is with the rest of the programming model which he has not yet justified as having merit. Nikunj http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: It appears that Database, SQLTransactionCallback, SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction, SQLStatementCallback, and SQLStatementErrorCallback interfaces can all be eliminated from WebDatabase completely. Given WebWorkers and DatabaseSync, why do we need the Database object at all? Are there use cases that cannot be satisfied by the combination of the two that? All use cases are implementable with workers + synchronous databases given enough effort. This is really good to know. This likely means that the WG would be required to find strong reasons to keep the duplication. But using workers is a large burden: they are completely separate JavaScript environments that share nothing with the main web page. Having to use that for simpler use cases would be very unfortunate. I am not sure how large a burden this is. Can you quantify it? Can you explain why this would be unacceptable? Well, Dimitri Glazkov wrote an emulation of HTML5 Database awhile ago on top of Gears. This is a piece of what a developer would have to do to emulate the async database interface on top of workers + a sync interface: http://code.google.com/p/html-5-sql-player It is about 3.5 kb, but all it does is emulate the async interface inside a worker using a synchronous backend. A real emulation of HTML5 async databases on top of HTML5 sync databases would have to do this, but move the async API out into the document context and put a marshalling layer between the two parts, with tracking of open transactions and statements on both sides. So doing a real emulation would be quite a bit more complex. Let's say you could do it in 7kb. For comparison, jquery compressed is 56k. That's an increase of 12.5%. A lot. I would guess that half of uses of the database API are simpler and the async interface would address their needs. As one humble example, my personal notepad site Gearpad (http://aaronboodman.com/gearpad) uses Gears local storage and it would work just fine on top of the async database interface. And the total code size of that site is 25 kb. It was designed specifically to be small and fast. Adding another 7kb for storage seems excessive. If all we had was synchronous databases and you could only use them from workers, I think you'd immediately start seeing developers create JavaScript wrappers that look a lot like our current Database interface, because... If there is a good chance for a JavaScript library to thrive in this environment, then there is all the more reason for the WG to not bake in a required browser interface. It is a balancing act. Taking this approach is what has led to the need for 56kb JavaScript libraries to do basic UI on the web. And even though getElementsByTagName(), as one example, works fine, we have gone and added getElementsBySelector(). Because it makes sense to centralize commonly needed functionality in the browser rather than have every app reimplement it. There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. Yes, this is the model. Note that you only need to chain callbacks if you need to do javascript work after them. If you just need to do a bunch of statements, you can fire-and-forget and they will be queued. Or you can mix the two styles. 3. the only supported model of transaction isolation is serialization of all database access. This seems orthogonal to the discussion we're having, right? This is certainly foreign to most database developers. Editors and/or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. I can't speak to what most database developers will find foreign. Even though you work at a database company, I think it is hard for anyone to make generalization about what most of anyone
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:
On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:
But using workers is a large burden: they are
completely separate JavaScript environments that share nothing with
the main web page. Having to use that for simpler use cases would be
very unfortunate.
I am not sure how large a burden this is. Can you quantify it? Can
you explain why this would be unacceptable?
The cost of using a Worker is that all interaction with the actual Web
page and its data is through an asynchronous channel that only allows
transfer of relatively simple pure data objects (essentially, JSON).
The advantage is that you can write database access as simple straight-
line code. If you want to do a lot of database work and don't need to
interact with page contents or associated JavaScript data structures
in the middle or very extensively, a Worker using the synchronous API
will likely work well. If you only want to do a little bit of database
access, or you need to mix it heavily with page interaction, using the
async API from the main thread will likely be simpler.
The programming model espoused by WebDatabase's async portion is that:
1. the programmer does all the SQL work in one or more asynchronous
callbacks.
2. callbacks are always linear, however, the program performs its
own stack management to keep the requisite context around for doing
its processing inside asynchronous callbacks. If multiple calls to
the database are required to perform certain work, then the programs
become a chain of nested callbacks.
3. the only supported model of transaction isolation is
serialization of all database access.
This is certainly foreign to most database developers. Editors and/
or others share the burden of proof that there is no alternative to
this and that there is merit in standardizing a brand new
programming model.
JavaScript actually lets you write a series of nested callbacks in a
way that looks almost like straight-line code, by using function
expressions:
db.transaction(function(tx) {
tx.executeSQL(SELECT UserID FROM Users WHERE UserName = ?,
[userToBan], function(tx, firstResultSet) {
if (resultSet.rows.length 0) {
tx.executeSQL(INSERT INTO BannedUsers VALUES (?),
resultSet.rows[0]);
}
}
});
(Sorry for the contrived example and my likely syntax errors.)
Granted, this gets awkward if your logic gets considerably more
complicated.
Regards,
Maciej
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:43 PM, Aaron Boodman wrote: On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. Yes, this is the model. Note that you only need to chain callbacks if you need to do javascript work after them. If you just need to do a bunch of statements, you can fire-and-forget and they will be queued. Or you can mix the two styles. 3. the only supported model of transaction isolation is serialization of all database access. This seems orthogonal to the discussion we're having, right? Yes, but I included it for completeness sake. This is certainly foreign to most database developers. Editors and/ or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. I can't speak to what most database developers will find foreign. Even though you work at a database company, I think it is hard for anyone to make generalization about what most of anyone will think about anything. On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote: I think this is an important invariant, because otherwise script writers _will_ shoot themselves in the foot. These aren't professional database developers; Web authors span the gamut of developer experience from the novice who is writing code more by luck than by knowledge all the way to the UI designer who wound up stuck with the task for writing the UI logic but has no professional background in programing, let alone concurrency in databases. We can't be firing unexpected exceptions when their users happen to open two tabs to the same application at the same time, leaving data unsaved. The above text referred to a certain class of developers as being unable to cope with unexpected exceptions. Most Web authors are not experts at parsing specifications, I think you will agree. Database developers exist as a class. Most database developers are not UI programmers, I think you will agree. We all make generalizations and they are useful to a certain extent. They help us do language design, and I feel that one should identify the classes of developers and their readiness/preferences. The point is that database development is not new. There are already programming models available that people rely on for using applications in developing database-based applications. Why introduce yet another one? Just because someone proposed it and no one was interested in proposing another one? And we are talking here of standardizing one that is duplicating what can be achieved though JavaScript and much simpler, more conventional programming model. I think the odds are stacked against this one. What I can say is that given the requirements, this is the only interface I can imagine that works. I can also note that as a web developer, I didn't find this interface foreign. It is a bit unfortunate in the callbackyness, but I think it is a good tradeoff to be able to use databases without a worker. This design also has the advantage of having implementations in webkit and chromium so we at least know that it is implementable. Anything that is Turing complete, can be implemented. So what? Since when did the bar get lowered so much that only an existence proof is required? snip Also, the programming model is not that novel. It is a straightforward application of IOC to ensure that transactions are always closed. Aaron misunderstands me here as I have no objection, per se, to IOC or RAII. The problem is with the rest of the programming model which he has not yet justified as having merit. The merit is in that it meets the requirements and no other model does. It has already been confirmed that requirements were not adequately described for WebDatabase [1]. This argument is,
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:54 PM, Maciej Stachowiak wrote:
On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:
snip
JavaScript actually lets you write a series of nested callbacks in a
way that looks almost like straight-line code, by using function
expressions:
db.transaction(function(tx) {
tx.executeSQL(SELECT UserID FROM Users WHERE UserName = ?,
[userToBan], function(tx, firstResultSet) {
if (resultSet.rows.length 0) {
tx.executeSQL(INSERT INTO BannedUsers VALUES (?),
resultSet.rows[0]);
}
}
});
(Sorry for the contrived example and my likely syntax errors.)
Granted, this gets awkward if your logic gets considerably more
complicated.
And mine did get awkward, very quickly. I found it really hard to keep
myself sane through the development of asynchronous code that executes
transactionally and involves multiple sql statements.
My argument is that the program logic gets really complex, really fast
if you are doing anything complex using Database. On the other hand,
if your logic and SQL needs are really simple, you might as well use
the DatabaseSync interface and pay the price of marshaling and
unmarshaling, which may not be that much.
Alternatively, perhaps, we should consider doing something in
WebWorkers to deal with the overhead of sharing JavaScript objects
across VMs.
Nikunj
http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Alternatively, perhaps, we should consider doing something in WebWorkers to deal with the overhead of sharing JavaScript objects across VMs. That would lead to far greater complexity for both implementations and content authors than the complexity saved by removing the async interface. Regards, Maciej
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. / Jonas
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 7:45 PM, Jonas Sicking wrote: On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. Understood. I am simply asking to not standardize something which can be easily implemented in JavaScript, until we understand the implications of the novel programming model being proposed. Nikunj http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 8:07 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 27, 2009, at 7:45 PM, Jonas Sicking wrote: On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. Understood. I am simply asking to not standardize something which can be easily implemented in JavaScript, until we understand the implications of the novel programming model being proposed. Like Aaron, I don't see that there is any other solution to the three requirements that he listed. Given that, I think it's appropriate that the API is designed as it is. (Note though that I'm not a fan of the SQL API in general as I think SQL is the wrong tool here, hope to have an alternative proposal eventually). Designing APIs for the web is different from designing APIs for many other platforms. The fact that the resulting API comes out differently than elsewhere is not I think we can avoid. / Jonas
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: It appears that Database, SQLTransactionCallback, SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction, SQLStatementCallback, and SQLStatementErrorCallback interfaces can all be eliminated from WebDatabase completely. Given WebWorkers and DatabaseSync, why do we need the Database object at all? Are there use cases that cannot be satisfied by the combination of the two that? All use cases are implementable with workers + synchronous databases given enough effort. But using workers is a large burden: they are completely separate JavaScript environments that share nothing with the main web page. Having to use that for simpler use cases would be very unfortunate. If all we had was synchronous databases and you could only use them from workers, I think you'd immediately start seeing developers create JavaScript wrappers that look a lot like our current Database interface, because... There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. Also, the programming model is not that novel. It is a straightforward application of IOC to ensure that transactions are always closed. - a
