- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 21 Sep 2009 12:33:19 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Aaron Boodman <aa@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Sep 21, 2009, at 11:50 AM, Jonas Sicking wrote: > On Mon, Sep 21, 2009 at 11:09 AM, Nikunj R. Mehta > <nikunj.mehta@oracle.com> wrote: >> >> On Sep 21, 2009, at 10:47 AM, Aaron Boodman wrote: >> >> On Mon, Sep 21, 2009 at 10:33 AM, Nikunj R. Mehta <nikunj.mehta@oracle.com >> > >> wrote: >>> >>> I haven't seen any responses to the issues below. I hope the >>> editors can >>> respond to these and several other of my messages about the >>> WebDatabase >>> draft. >> >> I'm not an editor, but I'll take a swing at answering some of these >> based on >> my mental model for this feature. >> >>> >>> On Aug 31, 2009, at 3:56 PM, Nikunj R. Mehta wrote: >>> >>> SQLResultSetRowList >>> >>> The item() method may take a long time to process. Shouldn't this >>> have an >>> asynchronous version with a callback? >>> The ability to randomly access rows in the row set increases the >>> likelihood that the item operation will take an arbitrarily long >>> time. Plus, >>> supporting random access is very expensive on limited memory >>> devices. >>> >>> Offer next() and previous() methods that returns the next and >>> previous row >>> respectively. >>> Offer absolute() and relative() call that may fail. See >>> java.sql.ResultSet.absolute() and java.sql.ResultSet.relative(). >>> >>> The length attribute could require accessing all the rows, which >>> would use >>> too much memory on limited memory devices. >>> Specify that the SQLResultSetRowList that resulted from a call to >>> SQLTransaction.executeSql() can only be accessed during the >>> execution of the >>> associated SQLStatementCallback >> >> I don't think ResultSet should ever go to disk, it should be memory- >> backed >> only. >> >> I don't see that as being a reasonable requirement. What happens when >> databases store blob data and multiple rows with blobs of large >> sizes are in >> the result set? It is hard to justify this requirement because it >> gives >> advantage to certain implementations over others? > > If the spec can be made to return FileData objects, as defined by [1], > then the actual blob data does not need to be stored in memory, just > FileData objects with some sort of internal pointer to where the > actual data is stored. This is the solution localStorage is defined to > use. Could we actually relate the FileData with SQL without defining a means of writing to the database? Or would we have an asymmetric interface where writing is done as String and reading as FileData? LocalStorage depends on structured clone, whereas SQL doesn't deal with structured clone at all. So I am not sure if the analogy flows. But certainly, the idea is worth considering. > > [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html > > / Jonas > Nikunj http://o-micron.blogspot.com
Received on Monday, 21 September 2009 19:36:04 UTC