Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On Mon, Aug 6, 2012 at 7:13 PM, Kang-Hao (Kenny) Lu kangh...@oupeng.com wrote: (12/08/06 19:25), Lachlan Hunt wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. Both 1. and 2. would take some extra code in Gecko, in particular 1. I'd note that this is not just about comments. It's about EOF fixing. See [1] for other testcases. [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0524 (12/08/07 0:20), Tab Atkins Jr. wrote: Officially, 2.1 defines Kenny's example of html /* as tokenizing into IDENT WS DELIM DELIM, which is then an invalid selector since nothing recognizes those two delims as part of Selector's syntax. No, that's IDENT WS(S) BAD_COMMENT Ah, whoops, indeed. I forgot that BAD_COMMENT existed. This is compatible with Syntax's treatment, where it's recognized as a comment, but triggers a parse error. COMMENT is a bit special here and I think you might want to comment on other cases in [1]. Hm, kk. ~TJ
RE: Lazy Blob
Hi Glenn,
var xhr = new XMLHttpRequest();
xhr.open(GET, resource.jpg);
var urlObject = xhr.getURLObject();
var newURL = URL.getObjectURL(urlObject);
img.src = newURL;
It's neat and I like the idea, too. However, there is a reason that I prefer
our blob approaches:
=== Another XHR Approach
partial interface XMLHttpRequest {
Blob makeLazyBlob ();
};
Usage:
[Service]
var xhr = new XMLHttpRequest();
xhr.open(GET, /kitten.png, true);
xhr.setRequestHeader(Authorization, Basic DEADBEEF);
var blob =xhr.makeLazyBlob();
window.intent.postResult(blob);
From totally client developer's point of view, who perhaps do not care the
underlying details at all, it is absolutely transparent to use the obtained
blob as they used to deal with. (no matter which type of data the blob
contains)
[Client]
navigator.startActivity(intent, resultOK);
function resultOK (data) {
// *data* is a blob delivered by service end.
it can be a few MB of image file (kitten.png in the above example)
or a few MB of mp3 music file
or a few MB of raw text file
or a huge binary string
etc.
var blob = data;
var reader = new FileReader();
// developers have all the existing file reader options with no
additional concern such that they do any further operations with the result
reader.readAsDataURL(blob);
// or
reader.readAsBinaryString(blob);
// or
reader.readAsText(blob);
// or
reader.readAsArrayBuffer(blob);
}
Regards,
Jungkee
Jungkee Song
Samsung Electronics
Re: GamepadObserver (ie. MutationObserver + Gamepad)
On 08/07/2012 03:29 AM, Glenn Maynard wrote: On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: 5ms is quite low when the aim is 60Hz updates... but with incremental/generational GCs 5ms sounds very much possible. 5ms is an *eternity* when you're aiming for 60 FPS, where you only have 16.6ms per frame to play with. That's 30% of your CPU budget just for memory management. It doesn't matter if it's 5ms every 100 frames, since it's the worst case you have to optimize for. (I've spent a lot of time optimizing non-web games to stay at 60 FPS, and it's a battle of microseconds, optimizing away .1ms here and .2ms there, so calling 5ms quite low is a bit troubling.) It is quite different if you need to assume that GC takes 180-250ms or if it takes only 5ms. But sure, getting anything major done in 16.6ms, and even so that things work ok on slower machines too can be tricky.
Re: GamepadObserver (ie. MutationObserver + Gamepad)
On Tue, Aug 7, 2012 at 2:29 AM, Glenn Maynard gl...@zewt.org wrote: 5ms is an *eternity* when you're aiming for 60 FPS, where you only have 16.6ms per frame to play with. That's 30% of your CPU budget just for memory management. It doesn't matter if it's 5ms every 100 frames, since it's the worst case you have to optimize for. (I've spent a lot of time optimizing non-web games to stay at 60 FPS, and it's a battle of microseconds, optimizing away .1ms here and .2ms there, so calling 5ms quite low is a bit troubling.) On a sidenote, the coming Oculus Rift (VR headset with wide FOV) will be quite sensitive to lag/jitter and the aim to support that is to have a total RTT from input - display of no more than 20ms per frame, for every frame at preferably 120hz (the dev kit display ships @60hz)
Re: Lazy Blob
On Tue, Aug 7, 2012 at 4:07 AM, Jungkee Song jungkee.s...@samsung.comwrote: window.intent.postResult(blob); From totally client developer's point of view, who perhaps do not care the underlying details at all, it is absolutely transparent to use the obtained blob as they used to deal with. (no matter which type of data the blob contains) If you go down the nullable size route, the client developers do have to care: every piece of code that receives a Blob would have to test to make sure that the code still works if size is null. That said, if you want to go that way, you can make URLObject and Blob more interchangeable to users: make FileReader accept Blob or URLObject, so you can use it to read from URLObject just like Blob. Users will still have to be wary of the lack of .size and .type, but there's no avoiding that. This has the major benefit of keeping Blob's semantics very clear, as it doesn't make Blob.size itself nullable. A different option, equivalent to users, is to make URLObject a base class of Blob. URLObject would replace Blob in methods like FileReader.readAsDataURL, createObjectURL and all other places where methods can work without knowing the size in advance. It would have no methods or attributes (at least at the start). In other words, - URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). Aside from that, the previous URLObject approach is unchanged: creating URLObject requires no network fetches. This wouldn't change the behavior of Blobs themselves in any way. (I don't like listing multiple options. The latter option above seems like the better design. I only listed the simpler option as its lower surface area may make it easier to get traction with.) -- Glenn Maynard
Re: Lazy Blob
On Aug 7, 2012, at 17:06 , Glenn Maynard wrote: A different option, equivalent to users, is to make URLObject a base class of Blob. URLObject would replace Blob in methods like FileReader.readAsDataURL, createObjectURL and all other places where methods can work without knowing the size in advance. It would have no methods or attributes (at least at the start). In other words, - URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). +1 from me on this one. I get a sense that this could possibly be a consensus position (or at least I'm going to claim that it is so as to get disagreement to manifest). Assuming it is, the next steps are: • Having agreed on a solution, do we agree on the problem? (i.e. would this get implemented?) • If so, we can bake this as a standalone delta spec but it would make more sense to me to make the changes directly to the relevant specs, namely FileAPI and XHR. I've copied Anne, Arun, and Jonas — any thought? In either case, I'm happy to provide the content. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: IndexedDB and RegEx search
FWIW it's fairly hard to for a database to index arbitrary content for regexes, to the point where it's going to be hard to do MUCH better than simply filtering based on regex. Out of curiosity, would the free text search feature on that wiki page that Arthur provided meet your needs? it's more along the lines of what SQL 'LIKE' provides. On Tue, Jul 31, 2012 at 11:17 AM, Michael Brooks firealwayswo...@gmail.comwrote: I like IndexedDB and non-relational databases. One feature that is very useful is the ability to search by regular expression: http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-RegularExpressions from that page: An index on the field queried by regexp can increase performance significantly, as follows: - Simple prefix queries (also called rooted regexps) like /^prefix/ will make efficient use of the index (much like most SQL databases that use indexes for a LIKE 'prefix%' expression). This only works if the expression is left-rooted and the i (case-insensitivity) flag is not used. - All other queries will not make an efficient use of the index: all values in the index will be scanned and tested against the regular expression. While /^a/, /^a.*/, and /^a.*$/ are equivalent, they will have different performance characteristics. The latter two will be slower as they have to scan the whole string. The first format can stop scanning after the prefix is matched. By not having this feature, I can't port my application to IndexedDB from WebSQL because it relies upon LIKE statements for text search. Text search could easily be replaced by a RegEx search, however this feature is unfortunately not apart of IndexedDB. It seems like this feature was just forgotten when writing the spec of IndexedDB. One way to do this is to create a reverse index on the contents of the table that you would normally use 'like' for - this is basically what a freetext search would do. Create an objectStore on the side that maps tokens (i.e. what LIKE would tokenize, words) to keys in another table. This is the classic NoSQL way to solve this, and it's what SQL does under the hood. (But I agree it would be nice for IndexedDB to just do this for you!) Alec
[Bug 18320] Clarify how reconnection works after losing internet connectivity
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18320 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2012-08-07 18:03:12 UTC --- *** This bug has been marked as a duplicate of bug 15495 *** -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Widget access request policy
The access request policy says to address security concerns. This raises a few questions. One is what are the security concerns. Two is what of the previous DOM related security models does not address them. Three is unless all scripts are authored and packaged as widgets in accordance to/with the entire widget specification set it would seem that those security issues would remain. Can someone clarify?
RE: Lazy Blob
- URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). +1 from me on this one. +1. I get a sense that this could possibly be a consensus position (or at least I'm going to claim that it is so as to get disagreement to manifest). Assuming it is, the next steps are: . Having agreed on a solution, do we agree on the problem? (i.e. would this get implemented?) . If so, we can bake this as a standalone delta spec but it would make more sense to me to make the changes directly to the relevant specs, namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought? In either case, I'm happy to provide the content. Having hammered out a consensus, I would like to contribute to providing the content. Jungkee Jungkee Song Samsung Electronics
Re: Lazy Blob
On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song jungkee.s...@samsung.comwrote: - URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). +1 from me on this one. +1. I get a sense that this could possibly be a consensus position (or at least I'm going to claim that it is so as to get disagreement to manifest). Assuming it is, the next steps are: . Having agreed on a solution, do we agree on the problem? (i.e. would this get implemented?) . If so, we can bake this as a standalone delta spec but it would make more sense to me to make the changes directly to the relevant specs, namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought? In either case, I'm happy to provide the content. Having hammered out a consensus, I would like to contribute to providing the content. I would suggest using a different name than URLObject. I think that name will cause a lot of head scratching.
Re: Lazy Blob
On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams gl...@skynav.com wrote: I would suggest using a different name than URLObject. I think that name will cause a lot of head scratching. No disagreement there; that was just a placeholder. I'd suggest waiting for further input from Anne, Jonas and Arun (the editors of the specs in question) before spending much time coming up with a name, though. -- Glenn Maynard
Re: Lazy Blob
On Tue, Aug 7, 2012 at 7:38 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams gl...@skynav.com wrote: I would suggest using a different name than URLObject. I think that name will cause a lot of head scratching. No disagreement there; that was just a placeholder. I'd suggest waiting for further input from Anne, Jonas and Arun (the editors of the specs in question) before spending much time coming up with a name, though. sure... i don't have a suggested replacement, but i know a bad name when i see one; i'll defer to the editors to come up with something reasonable
