Re: [IndexedDB] Problems unprefixing IndexedDB
From: Kyle Huey > > Jonas mentioned earlier on this list that we unprefixed IndexedDB in > Firefox nightlies some time ago. We ran into a bit of a problem.[0] Most > of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell > authors to deal with prefixing with: > > var indexedDB = window.indexedDB || window.webkitIndexedDB || > window.mozIndexedDB || window.msIndexedDB || ... > > This code has a bug when executed at global scope. Because the properties > are on the prototype chain of the global object, 'var indexedDB' creates a > new property on the global. Not according to ECMA-262 Edition 5.1 or conforming implementations of it. Firefox's JS engine, SpiderMonkey, actually helped get ES5.1 to match JS reality and past editions, where ES5 tried to spec what you describe in the last paragraph cited above. We found that incompatible, rolled it back in https://bugzilla.mozilla.org/show_bug.cgi?id=632003 and filed an erratum on ES5 which was fixed for ES5.1 (the ISO version of ES5). Unfortunately this bug regressed SpiderMonkey to ES5 status quo ante: https://bugzilla.mozilla.org/show_bug.cgi?id=722121 I only just noticed, due to the unprefix-indexedDB issue you raise. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=781739 to get SpiderMonkey fixed. The takeaway is to never assume a recently modified JS engine matches the latest ECMA spec. Sad to report this one involved SpiderMonkey, but it hits all evolving engines, and the spec can have bugs too (as described above in ES5). The ES5.1 spec is quite clear that the prototype chain is checked and no such property found, before a 'var' declaration makes a fresh binding with default value undefined. So no need for WebIDL, IndexedDB, or ES5.1 to change. /be
Re: [IndexedDB] Problems unprefixing IndexedDB
On Fri, Aug 10, 2012 at 5:47 AM, Glenn Maynard wrote:
> That makes it impossible for *anyone* to avoid breakage (unless they add the
> unprefixed version before unprefixing happens). You're exchanging avoidable
> breakage for unavoidable breakage, which doesn't make sense.
It's not unavoidable. You just have to future-proof your code. For instance:
if (!("indexedDB" in window)) {
window.indexedDB =
"webkitIndexedDB" in window ? window.webkitIndexedDB
: "mozIndexedDB" in window ? window.mozIndexedDB
: ...
}
So it's possible, but authors probably won't do it, because it's not
necessary to get their pages to work. So I reiterate that what makes
sense is just not to ship prefixed features in stable browser versions
at all. Experience has clearly shown that authors just paper over the
prefixes anyway -- in CSS they repeat the exact same declaration for
each prefix, and in JavaScript they do something like the above. This
basically eliminates any benefit of prefixing, since what authors do
is equivalent to all browsers using the same property name anyway,
except it's worse in a few ways:
1) It makes it harder for authors to use the feature. They have to
add extra lines of JS, or specify the same CSS repeatedly.
2) Authors might omit the unprefixed property, since initially it
won't hurt anything, and there are those who encourage them to do so.
This means that either browsers support the prefixed versions forever,
or they break some pages.
3) Authors won't necessarily account for all prefixes. This
disadvantages minor browsers, or those who add support for the feature
later -- unless they start recognizing their competitors' prefixes,
which just makes the entire convention even more of a farce than it
already is. This means we're stuck with a permanent reduction in
interop: there will always be some pages that will work in some
browsers but not others, because they don't specify the full set of
prefixes. (This would only be fixed if either all browsers recognized
all prefixes, so that such pages would work in all browsers; or no
browser recognized any prefix, so that such pages would break in all
browsers.)
The short version of the story is: everyone should stop shipping any
new prefixed properties in stable builds, now. (Unstable builds are
probably fine if they have few enough users, like maybe Aurora/nightly
for Firefox or dev for Chrome, because then not many pages will use
the feature.) And for existing properties that were already shipped
with prefixes, everyone should recognize all known prefixed variants,
plus the unprefixed variant, and keep that support forever. (Since
most browsers are not going to drop support for their own prefix, so
there's no other way to get interop.)
But this has been discussed to death on standards fora, and no one has
reached agreement, so it's up to individual browsers to act as they
see fit. Fortunately, at least Firefox now seems set to not ship any
new prefixed CSS properties in stable releases. I hope that policy
will apply to non-CSS features too going forward.
For the immediate problem, my personal opinion would be that Gecko
should make mozIndexedDB a permanent alias of indexedDB -- *along*
with msIndexedDB and webkitIndexedDB, with a console warning if the
prefixed properties are accessed saying that the aliases are
nonstandard. That makes as many pages as possible work. On the other
hand, it also doesn't disadvantage other browsers by favoring pages
that use mozIndexedDB.
Re: RfC: LCWD of WebSocket API; deadline August 30
No technical comments.
A few editorial comments.
> CLOSING (numeric value 2)
> The connection is going through the closing handshake.
The readyState can enter CLOSING also when close() is called before
establishment. In that case, it's not going through closing handshake.
> // networking
> attribute EventHandleronopen;
insert an SP between EventHandler and onopen
(already fixed on the editor's draft)
> When the user agent validates the server's response during the "establish
a WebSocket connection" algorithm, if the status code received from the
server is not 101 (e.g. it is a redirect), the user agent must fail the
websocket connection.
websocket -> WebSocket
> If the user agent was required to fail the websocket connection or the
WebSocket connection is closed with prejudice, fire a simple event named
error at the WebSocket object. [WSP]
websocket -> WebSocket
> interface CloseEvent : Event {
> readonly attribute boolean wasClean;
> readonly attribute unsigned short code;
> readonly attribute DOMString reason;
> };
missing anchor on reason to its description
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/9/12 10:56 PM, Boris Zbarsky wrote: On 8/9/12 10:47 PM, Glenn Maynard wrote: Meanwhile, pages will continue to work in other browsers that do this more sensibly. The main other option is basically to never drop the prefixed version, ever, which is what said "other browsers" actually do in practice. Or to make this more clear: As one of the few UAs that actually drops prefixed versions, we have tried dropping them after a deprecation period and we have tried dropping them immediately. So we have some actual experience with this sort of thing. And in our experience, if the prefixed property wasn't available for very long, dropping it immediately leads to fewer problems than does dropping it after a deprecation period. Of course if the property was available for a while and is widely used (-moz-opacity comes to mind), a deprecation period does help ameliorate things somewhat. -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/9/12 10:47 PM, Glenn Maynard wrote: That makes it impossible for *anyone* to avoid breakage (unless they add the unprefixed version before unprefixing happens). Or unless they avoid using prefixed things in production code to start with. Which brings us back to not shipping unstable stuff in production browsers, so people don't start using it. Meanwhile, pages will continue to work in other browsers that do this more sensibly. The main other option is basically to never drop the prefixed version, ever, which is what said "other browsers" actually do in practice. -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
On Thu, Aug 9, 2012 at 9:38 PM, L. David Baron wrote: > On Wednesday 2012-08-08 21:16 -0500, Glenn Maynard wrote: > > APIs should always be shipped prefixed and unprefixed for a reasonable > > period, so people have an opportunity to add the unprefixed name to their > > site before the unprefixed name goes away. > > Except that authors don't notice that they need to do so until the > unprefixed name goes away and causes pages to break. So it's better > if that happens sooner rather than later, so fewer total authors > will have to deal with the resulting broken pages. > That makes it impossible for *anyone* to avoid breakage (unless they add the unprefixed version before unprefixing happens). You're exchanging avoidable breakage for unavoidable breakage, which doesn't make sense. Meanwhile, pages will continue to work in other browsers that do this more sensibly. -- Glenn Maynard
Re: [IndexedDB] Problems unprefixing IndexedDB
On Wednesday 2012-08-08 21:16 -0500, Glenn Maynard wrote: > APIs should always be shipped prefixed and unprefixed for a reasonable > period, so people have an opportunity to add the unprefixed name to their > site before the unprefixed name goes away. Except that authors don't notice that they need to do so until the unprefixed name goes away and causes pages to break. So it's better if that happens sooner rather than later, so fewer total authors will have to deal with the resulting broken pages. -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla http://www.mozilla.org/ š¯„‚
Re: [IndexedDB] Problems unprefixing IndexedDB
Boris Zbarsky: Just for Window? What about interfaces Window inherits from? Them too. An why not for operations? Seems like exactly the same issue arises with: var requestAnimationFrame = window.requestAnimationFrame || ; I was thinking that properties for operations have always been on prototypes, so people would already be used to var shadowing them. You are right though that if people use that same pattern, they will fail similarly. Are there pages that rely on var shadowing for certain names and having the variable start off undefined? I can only assume there are. If so, then we might need to pick a set of names where shadowing still works despite there being a property on the prototype for an IDL attribute or operation.
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/9/12 9:44 PM, Cameron McCormack wrote: Kyle Huey: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. The problem seems to be because Web IDL moved properties from IDL attributes up to the prototype Just a point of record: they were already there in many implementations. and that changed `var attributeName;` behaviour. No, that changed when the ES spec changed how 'var' works recently... It didn't use to shadow things the way it does now, iirc. What if we change window's [[DefineOwnProperty]] so that if it would create a shadowing property for a name that corresponds to an IDL attribute on Window (or one of its mixed in interfaces), it doesn't do that? But not for operations. Just for Window? What about interfaces Window inherits from? An why not for operations? Seems like exactly the same issue arises with: var requestAnimationFrame = window.requestAnimationFrame || ; -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
Kyle Huey: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. The problem seems to be because Web IDL moved properties from IDL attributes up to the prototype, and that changed `var attributeName;` behaviour. My bad, I didn't realise that'd break things. What if we change window's [[DefineOwnProperty]] so that if it would create a shadowing property for a name that corresponds to an IDL attribute on Window (or one of its mixed in interfaces), it doesn't do that? But not for operations.
Re: IndexedDB and RegEx search
> > This is somewhat similar to [1] and something we decided was
> > out-of-scope for v1. But for v2 I definitely think we should look at
> > mechanisms for using JS code to filter/sort/index data in such a way
> > that the JS code is run on the IO thread.
> >
> > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=1
>
> There's a lot of excellent prior art in CouchDB for what you're describing
> in that bug (or at least parts thereof). I think it's well worth looking at.
>
>
If I understand CouchDB correctly, much like the suggestion elsewhere in
this thread, CouchDB's views are really indexing primitives that support
callbacks - the callbacks are (more or less) run at most once per document
as the document is stored (or soon after) - rather than every time a cursor
is created/iterated. This means that cursor iteration can still be very
fast.
I could be wrong, but I theorize MOST of the use cases for filters are more
or less static/stateless, and that if you want to iterate once using a
specific stateless callback/filter, then you'll probably going to want to
iterate it again, many times. That particular usecase just begs for an
index. Meaning, you probably want have code something like:
objectStore.openCursor(function(value) { return value.foo > value.bar;
}).onsuccess = ...
this could be done with a callback-based index:
objectStore.createIndex("foobigger", function(value) { return value.foo >
value.bar });
objectStore.index("foobigger").openCursor(IDBKeyRange.only(true));
The next use case is for some kind of semi-static cursor, where the
function isn't stateless, but it's parameterized by another value:
var maxDifference = calculateMaxDifference()
objectStore.openCursor(function(value) { return (value.foo - value.bar) <
maxDifference; }).onsuccess = ...;
This too can be implemented/expressed with a callback-based index, such
that the check for "< maxDifference" is more of a range call:
objectStore.index("difference").openCursor(IDBKeyRange.upperBound(maxDifference))
the final case I see is something where the callback really is stateful:
objectStore.openCursor(function (value) { return (model.validate(value));
}).onsuccess = ...;
Assuming model is fairly dynamic and well out of scope of indexing (i.e.
validation can't be expressed on some linear scale that can be
range-queried with IDBKeyRange)
This is a MUCH harder problem that has all sorts of security issues that
would need to be thought through... but the other use cases could still be
addressed by indexes.
I think part of the overall problem is that it's really rather cumbersome
to create/remove indexes in IndexedDB - you need to change the database
version to trigger a versionchange event, etc... it would be much nicer if
there were ways to dynamically create them on the fly, or add them as
needed. This has been brought up here in other contexts...
I wonder if in IndexedDB v2 we could support creating indexes on the fly -
I think indexeddb is trying too hard to enforce some kind of schema
versioning that is tied to indexes, that handles a very strict usecase of
lock-step schema changes, but I'm not sure everyone really needs that. I
think that's a burden we should leave to consumers of the API.
I'd much rather be able to say, in any transaction:
if (!('myindex' in objectStore.indexNames) {
objectStore.createIndex('myindex',);
}
Anyway, that's fodder for another thread :)
Alec
--
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>
Re: [IndexedDB] Problems unprefixing IndexedDB
On 8/9/12 9:10 AM, Odin HĆørthe Omdal wrote: We will get this specific IDB problem too Will you? In my testing, Opera seemed to put Window properties directly on the global, not on the global's prototype, unlike other DOM objects -Boris
Re: [IndexedDB] Problems unprefixing IndexedDB
On Thu, Aug 9, 2012 at 3:53 PM, Robin Berjon wrote: > Trying to evangelise that something is experimental is unlikely to succeed. > But when trying out a new API people do look at the console a lot (you tend > to have to :). It might be useful to emit a warning upon the first usage of > an experimental interface, of the kind "You are using WormholeTeleportation > which is an experimental API and may change radically at any time. You have > been warned." IMO, this is just the wrong attitude to take to the problem. The problem is not that authors are unwisely using experimental features and we should pressure them not to. The problem is that authors are quite rationally using features that are useful in the real world, and some people are sad that this means we have to actually stop changing them once they're used. The solution is not to get authors to use shipped features less. You aren't going to convince authors to stop using useful features no matter how much you insist they're experimental. The solution is for implementers to consider all shipped features frozen until proven otherwise, and stop maintaining the pretense that widely-used features are experimental or changeable just because they're behind a vendor prefix. It would help a lot if implementers stopped shipping new prefixed features to stable channels. I believe Mozilla already intends to do that for CSS features, and I hope it does so for DOM features too. If a feature is really unstable, don't ship it to enough users that you're creating a compat burden on yourself.
Re: [IndexedDB] Problems unprefixing IndexedDB
On Thu, 09 Aug 2012 14:53:06 +0200, Robin Berjon wrote: On Aug 9, 2012, at 02:28 , Boris Zbarsky wrote: On 8/8/12 8:23 PM, Adam Barth wrote: If we're telling people to use that pattern, we might as well just not prefix the API in the first place because that pattern just tells the web developers to unilaterally unprefix the API themselves. Yep. The only benefit of the prefixing at that point is to maybe mark the API as experimental, if any web developers pay attention. Which I doubt. Trying to evangelise that something is experimental is unlikely to succeed. But when trying out a new API people do look at the console a lot (you tend to have to :). It might be useful to emit a warning upon the first usage of an experimental interface, of the kind "You are using WormholeTeleportation which is an experimental API and may change radically at any time. You have been warned." Actually, you should say "*will* change, and *will*stop*working* after some time. If you don't update your code, we will break it". cheers -- Chaals - standards declaimer
Re: [IndexedDB] Problems unprefixing IndexedDB
On Thu, 09 Aug 2012 02:28:38 +0200, Ian Hickson wrote: On Wed, 8 Aug 2012, Kyle Huey wrote: PS. We're also going to run into this in the future with any other prefixed DOM APIs we add to the global, probably even if we don't tell people to do it wrong in our tutorials. This behavior is a pretty massive footgun. Not prefixing, and instead having spec authors make sure that what they spec is compatible with what has shipped (at the very least by changing names when they change semantics), is of course the right solution here. Yes, and also shipping very experimental stuff under a settings helps it being easy to change semantics even with the same name. We will get this specific IDB problem too, and we don't have a prefixed name to fall back on (although I saw one blog preemptively put an OIndexedDB in there (which warms my heart)), I'd like to try to keep it as-is and evangelize in this instance, although I won't be hard to convince based on what others do. -- Odin HĆørthe Omdal (Velmont/odinho) Ā· Core, Opera Software, http://opera.com
Re: [IndexedDB] Problems unprefixing IndexedDB
On Aug 9, 2012, at 02:28 , Boris Zbarsky wrote: > On 8/8/12 8:23 PM, Adam Barth wrote: >> If we're telling people to use that pattern, we might as well just not >> prefix the API in the first place because that pattern just tells the >> web developers to unilaterally unprefix the API themselves. > > Yep. The only benefit of the prefixing at that point is to maybe mark the > API as experimental, if any web developers pay attention. Which I doubt. Trying to evangelise that something is experimental is unlikely to succeed. But when trying out a new API people do look at the console a lot (you tend to have to :). It might be useful to emit a warning upon the first usage of an experimental interface, of the kind "You are using WormholeTeleportation which is an experimental API and may change radically at any time. You have been warned." -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8
On 9 Aug 2012, at 13:10, "Chaals McCathieNevile" wrote: > On Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow > wrote: > >> Chaals, Marcos, >> >> Based on this discussion, I concluded this CfC has failed to show we have >> consensus. As such, after you two have agreed on a version of the spec that >> satisfies all of Chaals' concerns, my recommendation is we start a new CfC. > > Works for me. Marcos, should I just send you a snippet for references? Yep. Would appreciate that. > > cheers > >> -Thanks, AB >> >> On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote: >>> On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres wrote: >>> On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote: > On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow (mailto:art.bars...@nokia.com)> > wrote: > > > Marcos would like to publish a "Proposed Edited Recommendation" [PER] > > > of the Widget Packaging and XML Configuration spec [REC] to > > incorporate the spec's errata and this is a Call for Consensus to do > > so. > > Currently I object. I would support the publication if: > > 1. It restored the pointer to an external errata document (Marcos is > clever, but there may still be errata) and Not sure what you mean here (and not just about being clever!:) )? There is a pointer to errataā€¦ http://dev.w3.org/2006/waf/widgets/errata.html It's right at the top of the document? What am I missing? >>> >>> The new version says that it incorporates the errata there, but removes the >>> statement that any further errata might be found at the same place. I >>> suggest reinstating the text that was taken out, since there may be a need >>> for errata on this document (personally I would prefer to see a new >>> version, allowing for example internationalisation of more elements) >>> > 2. It restored the status of the document to cover patent policy and > where to send feedback and Ah, sorryā€¦ SoTD was from the editor's draft. I need to find a boilerplate for a PER. I'm going to copy the one from XML 5th Ed., but it's a bit of work so I'll do it RSN. >>> >>> OK, please do. >>> > 3. It fixes the normative references to include authors and point to > stable versions. I will only link to "stable" versions for normative references - informative references don't matter. >>> >>> I can live with that. However I note that it is useful to know what version >>> of something that you used as an informative reference was the one you >>> actually read. HTML5 is different from what it was when P&C was published. >>> For most cases it doesn't matter (it is useful to have a link to the latest >>> and greatest version with all the brilliant ideas the editor had after a >>> saturday-night binge included), but for careful use of the documents it can >>> actually make a material difference. >>> Re editors: can't find anything in the process document that requires them to be added. >>> >>> 1. It is a generally accepted convention that assists in recognising a >>> reference, particularly from a printed version (yes, people still print >>> specifications, often. There are sound reasons why this is likely to >>> continue for some years). >>> 2. Many of these publications are essentially volunteer work. The efforts >>> of the editors (or the money of their employers that supports them taking >>> on the work) are often motivated in part by the fact that their name is >>> cited by convention. I don't see the use case for breaking this convention, >>> and the small benefit that it provides to those who edit specifications. >>> Of course, you are more than invited to add them yourself to the spec if you really want. >>> >>> Sure, I can do that. >>> They were in the REC, so you can copy/paste them from there (or email me the markup and I'll paste them in for you). However, I see no use case for including them given that there is a hyperlink to their spec (which already lists them). >>> >>> Cheers >>> >>> Chaals >>> >> >> > > > -- > Chaals - standards declaimer
Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8
On 9 Aug 2012, at 12:52, Arthur Barstow wrote: > Chaals, Marcos, > > Based on this discussion, I concluded this CfC has failed to show we have > consensus. As such, after you two have agreed on a version of the spec that > satisfies all of Chaals' concerns, my recommendation is we start a new CfC. Sure, go for it. Charles just needs to send me the updated refs and I need to update the SoTD. No biggy. We should have that by end of next week I would guess. Nothing is really a blocker there. > > -Thanks, AB > > On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote: >> On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres wrote: >> >>> On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote: >>> On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow >>> (mailto:art.bars...@nokia.com)> wrote: > Marcos would like to publish a "Proposed Edited Recommendation" [PER] > > of the Widget Packaging and XML Configuration spec [REC] to > incorporate the spec's errata and this is a Call for Consensus to do > so. Currently I object. I would support the publication if: 1. It restored the pointer to an external errata document (Marcos is clever, but there may still be errata) and >>> >>> Not sure what you mean here (and not just about being clever!:) )? There is >>> a pointer to errataā€¦ >>> http://dev.w3.org/2006/waf/widgets/errata.html >>> It's right at the top of the document? What am I missing? >> >> The new version says that it incorporates the errata there, but removes the >> statement that any further errata might be found at the same place. I >> suggest reinstating the text that was taken out, since there may be a need >> for errata on this document (personally I would prefer to see a new version, >> allowing for example internationalisation of more elements) >> 2. It restored the status of the document to cover patent policy and where to send feedback and >>> >>> Ah, sorryā€¦ SoTD was from the editor's draft. I need to find a boilerplate >>> for a PER. I'm going to copy the one from XML 5th Ed., but it's a bit of >>> work so I'll do it RSN. >> >> OK, please do. >> 3. It fixes the normative references to include authors and point to stable versions. >>> >>> I will only link to "stable" versions for normative references - >>> informative references don't matter. >> >> I can live with that. However I note that it is useful to know what version >> of something that you used as an informative reference was the one you >> actually read. HTML5 is different from what it was when P&C was published. >> For most cases it doesn't matter (it is useful to have a link to the latest >> and greatest version with all the brilliant ideas the editor had after a >> saturday-night binge included), but for careful use of the documents it can >> actually make a material difference. >> >>> Re editors: can't find anything in the process document that requires them >>> to be added. >> >> 1. It is a generally accepted convention that assists in recognising a >> reference, particularly from a printed version (yes, people still print >> specifications, often. There are sound reasons why this is likely to >> continue for some years). >> 2. Many of these publications are essentially volunteer work. The efforts of >> the editors (or the money of their employers that supports them taking on >> the work) are often motivated in part by the fact that their name is cited >> by convention. I don't see the use case for breaking this convention, and >> the small benefit that it provides to those who edit specifications. >> >>> Of course, you are more than invited to add them yourself to the >>> spec if you really want. >> >> Sure, I can do that. >> >>> They were in the REC, so you can copy/paste them from there (or email me >>> the markup and I'll paste them in for you). However, I see no use case for >>> including them given that there is a hyperlink to their spec (which already >>> lists them). >> >> Cheers >> >> Chaals >> > >
Re: IndexedDB and RegEx search
On Aug 9, 2012, at 01:39 , Jonas Sicking wrote:
> On Wed, Aug 8, 2012 at 1:33 AM, Yuval Sadan wrote:
>> Perhaps it shouldn't be a full-text *index* but simply a search feature.
>> Though I'm unfamiliar with specific implementations, I gather that filtering
>> records in native code would save (possibly lots of) redundant JS object
>> construction (time and memory = money :)), and doing so with a pre-compiled
>> regex might improve over certain JS implementation or non-optimizable
>> practices, e.g.
>> function search(field, s) {
>> someCallToIndexedDb(function filter(record) {
>>var re = new RegExp(s);
>>return !re.test(record[field]);
>> }
>> }
>>
>> Plus it saves some code jumbling for a rather common practice.
>
> The main thing you'd save is having to round-trip between threads for
> each record. I think a more general feature that would be more
> interesting would be to be able to iterate an index or objectStore
> using a cursor, but at the time of constructing the cursor be able to
> provide a javascript function which can be used to filter the data.
> Unfortunately javascript doesn't have a good way of executing a
> function in such a way that it doesn't pull in a lot of context, but
> it's possible to hack this, for example by passing a string which
> contains the javascript code.
Actually, PhantomJS does perform some weird function decontextualisation in
order to execute part of your code in a different context (that of the page you
just loaded). But it's weird, surprising to developers, and ugly so I agree
it's not a model to emulate.
We do, however, have Workers. It seems to me that there could be a way to make
that work.
> This is somewhat similar to [1] and something we decided was
> out-of-scope for v1. But for v2 I definitely think we should look at
> mechanisms for using JS code to filter/sort/index data in such a way
> that the JS code is run on the IO thread.
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=1
There's a lot of excellent prior art in CouchDB for what you're describing in
that bug (or at least parts thereof). I think it's well worth looking at.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8
On Thu, 09 Aug 2012 13:52:26 +0200, Arthur Barstow wrote: Chaals, Marcos, Based on this discussion, I concluded this CfC has failed to show we have consensus. As such, after you two have agreed on a version of the spec that satisfies all of Chaals' concerns, my recommendation is we start a new CfC. Works for me. Marcos, should I just send you a snippet for references? cheers -Thanks, AB On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote: On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres wrote: On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote: On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow mailto:art.bars...@nokia.com)> wrote: > Marcos would like to publish a "Proposed Edited Recommendation" [PER] > of the Widget Packaging and XML Configuration spec [REC] to > incorporate the spec's errata and this is a Call for Consensus to do > so. Currently I object. I would support the publication if: 1. It restored the pointer to an external errata document (Marcos is clever, but there may still be errata) and Not sure what you mean here (and not just about being clever!:) )? There is a pointer to errataā€¦ http://dev.w3.org/2006/waf/widgets/errata.html It's right at the top of the document? What am I missing? The new version says that it incorporates the errata there, but removes the statement that any further errata might be found at the same place. I suggest reinstating the text that was taken out, since there may be a need for errata on this document (personally I would prefer to see a new version, allowing for example internationalisation of more elements) 2. It restored the status of the document to cover patent policy and where to send feedback and Ah, sorryā€¦ SoTD was from the editor's draft. I need to find a boilerplate for a PER. I'm going to copy the one from XML 5th Ed., but it's a bit of work so I'll do it RSN. OK, please do. 3. It fixes the normative references to include authors and point to stable versions. I will only link to "stable" versions for normative references - informative references don't matter. I can live with that. However I note that it is useful to know what version of something that you used as an informative reference was the one you actually read. HTML5 is different from what it was when P&C was published. For most cases it doesn't matter (it is useful to have a link to the latest and greatest version with all the brilliant ideas the editor had after a saturday-night binge included), but for careful use of the documents it can actually make a material difference. Re editors: can't find anything in the process document that requires them to be added. 1. It is a generally accepted convention that assists in recognising a reference, particularly from a printed version (yes, people still print specifications, often. There are sound reasons why this is likely to continue for some years). 2. Many of these publications are essentially volunteer work. The efforts of the editors (or the money of their employers that supports them taking on the work) are often motivated in part by the fact that their name is cited by convention. I don't see the use case for breaking this convention, and the small benefit that it provides to those who edit specifications. Of course, you are more than invited to add them yourself to the spec if you really want. Sure, I can do that. They were in the REC, so you can copy/paste them from there (or email me the markup and I'll paste them in for you). However, I see no use case for including them given that there is a hyperlink to their spec (which already lists them). Cheers Chaals -- Chaals - standards declaimer
Re: CfC: publish Widgets P&C as a "Proposed Edited Recommendation"; deadline August 8
Chaals, Marcos, Based on this discussion, I concluded this CfC has failed to show we have consensus. As such, after you two have agreed on a version of the spec that satisfies all of Chaals' concerns, my recommendation is we start a new CfC. -Thanks, AB On 7/26/12 9:52 AM, ext Chaals McCathieNevile wrote: On Wed, 25 Jul 2012 22:17:42 +0200, Marcos Caceres wrote: On Wednesday, 25 July 2012 at 19:02, Chaals McCathieNevile wrote: On Wed, 25 Jul 2012 18:26:44 +0200, Arthur Barstow mailto:art.bars...@nokia.com)> wrote: > Marcos would like to publish a "Proposed Edited Recommendation" [PER] > of the Widget Packaging and XML Configuration spec [REC] to > incorporate the spec's errata and this is a Call for Consensus to do > so. Currently I object. I would support the publication if: 1. It restored the pointer to an external errata document (Marcos is clever, but there may still be errata) and Not sure what you mean here (and not just about being clever!:) )? There is a pointer to errataā€¦ http://dev.w3.org/2006/waf/widgets/errata.html It's right at the top of the document? What am I missing? The new version says that it incorporates the errata there, but removes the statement that any further errata might be found at the same place. I suggest reinstating the text that was taken out, since there may be a need for errata on this document (personally I would prefer to see a new version, allowing for example internationalisation of more elements) 2. It restored the status of the document to cover patent policy and where to send feedback and Ah, sorryā€¦ SoTD was from the editor's draft. I need to find a boilerplate for a PER. I'm going to copy the one from XML 5th Ed., but it's a bit of work so I'll do it RSN. OK, please do. 3. It fixes the normative references to include authors and point to stable versions. I will only link to "stable" versions for normative references - informative references don't matter. I can live with that. However I note that it is useful to know what version of something that you used as an informative reference was the one you actually read. HTML5 is different from what it was when P&C was published. For most cases it doesn't matter (it is useful to have a link to the latest and greatest version with all the brilliant ideas the editor had after a saturday-night binge included), but for careful use of the documents it can actually make a material difference. Re editors: can't find anything in the process document that requires them to be added. 1. It is a generally accepted convention that assists in recognising a reference, particularly from a printed version (yes, people still print specifications, often. There are sound reasons why this is likely to continue for some years). 2. Many of these publications are essentially volunteer work. The efforts of the editors (or the money of their employers that supports them taking on the work) are often motivated in part by the fact that their name is cited by convention. I don't see the use case for breaking this convention, and the small benefit that it provides to those who edit specifications. Of course, you are more than invited to add them yourself to the spec if you really want. Sure, I can do that. They were in the REC, so you can copy/paste them from there (or email me the markup and I'll paste them in for you). However, I see no use case for including them given that there is a hyperlink to their spec (which already lists them). Cheers Chaals
