- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 27 Jul 2009 21:41:54 -0700
- To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Aaron Boodman <aa@google.com>, public-webapps WG <public-webapps@w3.org>
On Mon, Jul 27, 2009 at 8:07 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com> wrote: > > On Jul 27, 2009, at 7:45 PM, Jonas Sicking wrote: > >> On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiak<mjs@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
Received on Tuesday, 28 July 2009 04:42:54 UTC