[IndexedDB] Events and requests
Hi All,
One of the things we briefly discussed at the summit was that we
should make IDBErrorEvents have a .transaction. This since we are
allowing you to place new requests from within error handlers, but we
currently provide no way to get from an error handler to any useful
objects. Instead developers will have to use closures to get to the
transaction or other object stores.
Another thing that is somewhat strange is that we only make the result
available through the success event. There is no way after that to get
it from the request. So instead we use special event interfaces with
supply access to source, transaction and result.
Compare this to how XMLHttpRequests work. Here the result and error
code is available on the request object itself. The 'load' event,
which is equivalent to our 'success' event didn't supply any
information until we recently added progress event support. But still
it only supplies information about the progress, not the actual value
itself.
One thing we could do is to move
.source
.transaction
.result
.error
to IDBRequest. Then make success and error events be simple events
which only implement the Event interface. I.e. we could get rid of the
IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
interfaces.
We'd still have to keep IDBVersionChangeEvent, but it can inherit
Event directly.
The request created from IDBFactory.open would return a IDBRequest
where .transaction and .source is null. We already fire a IDBEvent
where .source is null (actually, the spec currently doesn't define
what the source should be I see now).
The only major downside with this setup that I can see is that the
current syntax:
db.transaction([foo]).objectStore(foo).get(mykey).onsuccess = function(e) {
alert(e.result);
}
would turn into the slightly more verbose
db.transaction([foo]).objectStore(foo).get(mykey).onsuccess = function(e) {
alert(e.target.result);
}
(And note that with the error handling that we have discussed, the
above code snippets are actually plausible (apart from the alert() of
course)).
The upside that I can see is that we behave more like XMLHttpRequest.
It seems that people currently follow a coding pattern where they
place a request and at some later point hand the request to another
piece of code. At that point the code can either get the result from
the .result property, or install a onload handler and wait for the
result if it isn't yet available.
However I only have anecdotal evidence that this is a common coding
pattern, so not much to go on.
/ Jonas
Re: Comments on the http://www.w3.org/TR/widgets/
Hello Here are some issues/clarifications on the pc test suite 1. ta-uLHyIMvLwz/000 : dl.wgt The archive is not encrypted. The test description mentions that it is encrypted 2. i18n-lro/020 i18nlro20.wgt Is the expectation of the testcase correct. Should the word SED change to DES, to be in sync with the example The Awesome Super bdo dir=rtlDude/bdoWidget in pc spec. Does it expect the character to be changed from lt to gt. Same behavior applies to i18n-ltr 010 020, i18n-rlo 020 etc rgds viji On Wednesday 03 November 2010 10:17 AM, viji wrote: Hello Marcos Thank You, I am okay with the changes. rgds viji On Tuesday 02 November 2010 08:20 PM, Marcos Caceres wrote: On Tue, Nov 2, 2010 at 9:36 AM, vijiv...@borqs.com wrote: Hello Marcos The changes for Email attribute and Rule for Getting Text Content with Normalized White Space seem fine. Good to hear! I have a comment on usage of Global attributes for Icon, Feature, Content and Param elements. For all these elements dir attribute does not make sense. The text you added contains the line What effect specifying a global attribute has on an elements is determined by Step 7 of this specification. In step 7, the reference is given to Rule for Getting Text Content or rule for getting a single attribute value etc. Does this clarify as to whether dir attribute is applicable or not for the elements like Icon, Feature, Content and Param elements. Yes, these rules hopefully make it clear how and when dir and xml:lang are taken into consideration. You will notice that the rule for parsing a non-negative number does not take dir or xml:lang into account: http://www.w3.org/TR/widgets/#rule-for-parsing-a-non-negative-integer While the Rule for Getting Text Content always returns a localizable string: http://www.w3.org/TR/widgets/#rule-for-getting-text-content0 Please do take a look and see if the rules make sense. The reason we leave the global attributes there is for forward/backwards compatibility in case we want to add human readable text in the future. Consider this hypothetical example: feature name=some:feature dir=ltr otherns:role xml:lang=enThis feature is needed to do something useful/otherns:role /feature
RE: FPWD of Web Messaging; deadline November 13
Microsoft supports publication of a FPWD of Web Messaging. On Saturday, November 06, 2010 11:49 AM, Arthur Barstow wrote: Ian, All - during WebApps' November 1 gathering, participants expressed in an interest in publishing a First Public Working Draft of Web Messaging [1] and this is a CfC to do so: http://dev.w3.org/html5/postmsg/ This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is November 13. -Art Barstow [1] http://www.w3.org/2010/11/01-webapps-minutes.html#item04 Original Message Subject: ACTION-598: Start a CfC to publish a FPWD of Web Messaging (Web Applications Working Group) Date: Mon, 1 Nov 2010 11:35:29 +0100 From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group WG public-webapps@w3.org To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com ACTION-598: Start a CfC to publish a FPWD of Web Messaging (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/598 On: Arthur Barstow Due: 2010-11-08
Relational Data Model Example
Hi,
I have completed the first stage of the Relational Data Model prototype.
Error checking is not complete (for example aggregate functions can be
nested currently, and this should not be allowed). So it should work for
correct examples, but may not generate an error (or the correct error) for
incorrect examples.
The library (available at http://keean.fry-it.com/relational.js) only
implements the WebSQL backend at the moment, as this was the quickest to get
up and running. I plan to implement a JavaScript Object backend (IE
relational operations in memory) and the IndexedDB backend.
There is a simple first example (available at
http://keean.fry-it.com/cuboid.html) that shows calculating the average
volume of a collection of cuboids the relational way.
Attached at the end is the JavaScript source for the cuboid example.
Comments appreciated.
Cheers,
Keean.
try {
var rdm = new RelationalDataModel;
var rdb = new rdm.WebSQLiteDataAdapter;
var cuboid_id = rdm.domain('id', rdm.integer, {not_null: true});
var dimension = rdm.domain('dimension', rdm.number, {not_null:
true});
var cuboids = rdm.relation('cuboids', {
id: rdm.attribute('id', cuboid_id, {auto_increment: true}),
length: rdm.attribute('length', dimension),
width: rdm.attribute('width', dimension),
height: rdm.attribute('height', dimension)
});
var v = rdb.validate('cubeoid_db', 1.0, [cuboids]);
v.onerror = function(error) {
alert('ValidateError: ' + error.message);
};
v.onsuccess = function(db) {
var insert = db.transaction(function(tx) {
tx.insert(cuboids, {width:10.0, length:10.0, height:10.0});
tx.insert(cuboids, {width:13.5, length:17.2, height:10.1});
tx.insert(cuboids, {width:23.1, length:7.9, height:9.5});
});
insert.onerror = function(error) {
alert('InsertTransactionError: ' + error.message);
};
insert.onsuccess = function() {
var query = db.transaction(function(tx) {
var average_volume = cuboids.attributes.length
.mul(cuboids.attributes.width)
.mul(cuboids.attributes.height)
.avg();
var q = tx.query(cuboids.project({avg_vol:
average_volume}));
q.onsuccess = function(t, results) {
var s = ;
results.forEach(function(r) {
s += r.avg_vol + '\n';
});
alert(s);
};
});
query.onerror = function(error) {
alert('QueryTransactionError: ' + error.message);
};
};
};
} catch (e) {
alert (e.stack);
}
Re: CfC: to publish Web SQL Database as a Working Group Note; deadline November 13
I am glad to see this after having brought this up last year at TPAC. I support this. Nikunj On Nov 6, 2010, at 3:09 PM, Ian Hickson wrote: On Sat, 6 Nov 2010, Arthur Barstow wrote: [...] suggested the spec be published as a Working Group Note and this is Call for Consensus to do. I support this in principle. I can't commit to providing the draft, though. A few months ago I turned off this particular spigot in my publishing pipeline (back when I removed the section from the WHATWG complete.html spec) and I don't have the bandwidth to bring it back up to speed at this time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: to publish Web SQL Database as a Working Group Note; deadline November 13
I support this too. / Jonas On Tue, Nov 9, 2010 at 10:53 AM, Nikunj Mehta nik...@o-micron.com wrote: I am glad to see this after having brought this up last year at TPAC. I support this. Nikunj On Nov 6, 2010, at 3:09 PM, Ian Hickson wrote: On Sat, 6 Nov 2010, Arthur Barstow wrote: [...] suggested the spec be published as a Working Group Note and this is Call for Consensus to do. I support this in principle. I can't commit to providing the draft, though. A few months ago I turned off this particular spigot in my publishing pipeline (back when I removed the section from the WHATWG complete.html spec) and I don't have the bandwidth to bring it back up to speed at this time. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Bug 11276] New: Specify deleteDatabase
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11276 Summary: Specify deleteDatabase Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: jo...@sicking.cc ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org See thread started here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0346.html And the proposal here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0379.html with adjustment here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0382.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
Hi David, Sorry for the delayed response. I think the idea of BinaryHttpRequest is a reasonable one. As you point out, it simply side-steps any potential performance and compatibility issues. Are you imagining that the API is effectively the same as XMLHttpRequest, except without the text and XML part? How do other people feel about David's proposal? Chris On Wed, Nov 3, 2010 at 10:47 AM, David Flanagan da...@davidflanagan.comwrote: On 11/02/2010 07:06 PM, Boris Zbarsky wrote: On 11/2/10 4:04 PM, David Flanagan wrote: Boris (Mozilla) worries that creating a new mode in which responseText is unavailable will break jQuery applications. And various others where the consumer of the data and the XHR creator are not the same entity. jQuery is just an obvious example that we all know about, is public, and clearly illustrates the pattern It occurs to me now, however, that the way to avoid breaking jQuery is to make responseType a constructor argument instead of a property to be set before send(). If I recall correctly, jQuery always creates its own XHR object, so if responseType is only settable at creation time, then the situation Boris fears won't arise. At least not with that library. That last sentence is key there... ;) -Boris So if making responseType a constructor argument isn't enough to rescue the XHR API, that brings me back to my preferred solution: a new BinaryHttpRequest API. I think everyone on this thread has agreed that ease of use for web developers is more important than ease for implementors. As someone who documents stuff like this for web developers, I think I've got a pretty good handle on what is easy to use and what is not (documentation ease maps well to coding ease). So in my professional capacity I argue that having a separate new BinaryHttpRequest API would be conceptually simpler and easier for developers than having a single XMLHttpRequest object with both a legacy responseText property and a new response property and with properties like responseType or asBlob that put the object into special modes. It would also be easier to document a new binary API than it would be to document the optimization hints for the current API: be careful to not access both responseText and responseArrayBuffer because that may cause extra memory usage, although on some implementations that extra memory is going to be allocated no matter what you do. David
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote: Hi David, Sorry for the delayed response. I think the idea of BinaryHttpRequest is a reasonable one. As you point out, it simply side-steps any potential performance and compatibility issues. Are you imagining that the API is effectively the same as XMLHttpRequest, except without the text and XML part? How do other people feel about David's proposal? I'm in favor a new constructor. It seems silly to first hack ourselves into a corner by extending an API designed for text or XML, then try to hack our way out of the problems that causes. A new object that does what's needed seems like the cleanest and most correct solution to the problem. ~TJ
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote: Hi David, Sorry for the delayed response. I think the idea of BinaryHttpRequest is a reasonable one. As you point out, it simply side-steps any potential performance and compatibility issues. Are you imagining that the API is effectively the same as XMLHttpRequest, except without the text and XML part? How do other people feel about David's proposal? I still don't see the problem with the responseType. There's very little difference in both BinaryHttpRequest and responseType is opt-in mechanisms. The only difference is that .responseType allows a existing object (which a library could be holding a reference to) could be mutated since it now behaves differently. It seems to me that whenever this is done in the wrong way code should consistently fail, and so should be easy for developers to deal with. / Jonas
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On 11/9/10 2:54 PM, Chris Rogers wrote: Sorry for the delayed response. I think the idea of BinaryHttpRequest is a reasonable one. As you point out, it simply side-steps any potential performance and compatibility issues. Are you imagining that the API is effectively the same as XMLHttpRequest, except without the text and XML part? How do other people feel about David's proposal? I would be fine with it. -Boris
Re: XHR responseArrayBuffer attribute: suggestion to replace asBlob with responseType
On 11/09/2010 11:54 AM, Chris Rogers wrote: Hi David, Sorry for the delayed response. No problem. public-webapps got strangely quiet after I sent my last message, and I realized that everyone was off actually meeting about this stuff... I think the idea of BinaryHttpRequest is a reasonable one. As you point out, it simply side-steps any potential performance and compatibility issues. Are you imagining that the API is effectively the same as XMLHttpRequest, except without the text and XML part? Yes, roughly. Thinking about it now, maybe just calling the new API HttpRequest would be better than BinaryHttpRequest. It would support text, array buffers and blobs, but only one per request, selected via responseType and stored in a single response property. It might be nice to modify the open() method so that you could specify the response type as the 3rd argument. (If that argument was present, the boolean async flag would become the fourth argument...) You'd have to decide whether to continue to support readystatechange events or make a clean break from them with the new API. I've never understood the need for AnonXMLHttpRequest, so I don't know if a new Anon constructor would be required or if anonymity could be handled via a constructor argument or property. From a specification standpoint, you have to decide whether to just leave XHR as a legacy API at level 1 and then define something new in the Level 2 specification. This would presumably be a pretty easy change to the existing Level 2 draft. Or are we asking Anne to keep all the current XHR2 stuff and also add an HttpRequest object to support binary requests? That seems like a lot more work from a specification editing perspective. David How do other people feel about David's proposal? Chris On Wed, Nov 3, 2010 at 10:47 AM, David Flanagan da...@davidflanagan.com mailto:da...@davidflanagan.com wrote: On 11/02/2010 07:06 PM, Boris Zbarsky wrote: On 11/2/10 4:04 PM, David Flanagan wrote: Boris (Mozilla) worries that creating a new mode in which responseText is unavailable will break jQuery applications. And various others where the consumer of the data and the XHR creator are not the same entity. jQuery is just an obvious example that we all know about, is public, and clearly illustrates the pattern It occurs to me now, however, that the way to avoid breaking jQuery is to make responseType a constructor argument instead of a property to be set before send(). If I recall correctly, jQuery always creates its own XHR object, so if responseType is only settable at creation time, then the situation Boris fears won't arise. At least not with that library. That last sentence is key there... ;) -Boris So if making responseType a constructor argument isn't enough to rescue the XHR API, that brings me back to my preferred solution: a new BinaryHttpRequest API. I think everyone on this thread has agreed that ease of use for web developers is more important than ease for implementors. As someone who documents stuff like this for web developers, I think I've got a pretty good handle on what is easy to use and what is not (documentation ease maps well to coding ease). So in my professional capacity I argue that having a separate new BinaryHttpRequest API would be conceptually simpler and easier for developers than having a single XMLHttpRequest object with both a legacy responseText property and a new response property and with properties like responseType or asBlob that put the object into special modes. It would also be easier to document a new binary API than it would be to document the optimization hints for the current API: be careful to not access both responseText and responseArrayBuffer because that may cause extra memory usage, although on some implementations that extra memory is going to be allocated no matter what you do. David
[Bug 11280] New: IDBFactory.databases doesn't work
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11280
Summary: IDBFactory.databases doesn't work
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jo...@sicking.cc
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
I've somehow missed this until now, but apparently IDBFactory has a .databases
property.
While I could see the use for this, it can't be implemented in a non-racy way.
The problem is that other processes or threads can create and delete databases
at any time, so there is no way to guarantee that a database which existed when
.databases is checked, will exist a few milliseconds later when the knowledge
of a database's existence is used. For example
if (indexedDB.databases.contains(hello)) {
indexedDB.open(hello).onsuccess = ...;
}
has a race condition.
Another problem is that it can't be implemented without blocking the main
thread while going off to another thread or process where the indexedDB
implementation lives. It'll likely also require synchronous IO to get the list
of databases from file.
I suggest we simply remove it for now.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
