Re: [IndexedDB] Closing on bug 9903 (collations)
On 6 May 2011 03:00, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 4, 2011 at 11:12 PM, Keean Schupke ke...@fry-it.com wrote: On 5 May 2011 00:33, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 3, 2011 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think we should do callbacks for the first version of javascript. It gets very messy since we can't rely on that the script function will be returning stable values. The worst that would happen if it didn't return stable values is that sorting would return unpredictable results. Worst is an infinite loop - no return. So the choice here really is between only supporting some form of binary sorting, or supporting a built-in set of collations. Anything else will have to wait for version 2 in my opinion. I think it would be a mistake to try supporting a limited set of natural-language collations. Binary collation is fine for a first version. MySQL only supported binary collation up through version 4, for instance. A good point about MySQL. On Wed, May 4, 2011 at 3:49 AM, Keean Schupke ke...@fry-it.com wrote: I thought only the app that created the db could open it (for security reasons)... so it becomes the app's responsibility to do version control. The comparison function is not going to change by itself - someone has to go into the code and change it, when they do that they should up the revision of the database, if that change is incompatible. Why should we let such a pitfall exist if we can just store the function and avoid the issue? I don't see it as a pitfall, it is an has the advantage of transparency. There is exactly the same problem with object properties. If the app changes to expect a new property on all objects stored, then the app has to correctly deal with the update. If a requested property doesn't exist, I assume the API will fail immediately with a clear error code. It will not fail silently and mysteriously with no error code. (Again, I haven't looked at it closely, or tried to use it.) What if the new version uses the same property name for a different thing? For example in V1 'Employer' is a string name, and in V2 'Employer' is a reference to another object. You may say 'you should change the column name'? Right thats just the same as me saying you should change the DB version number when you change the collation algorithm. Its the same thing. People seem to be making a big fuss about having a non-persisted collation function defined in user code, when many many things require the code to have the correct model of the data stored in the database to work properly. It seems illogical to make a special case for this function, and not do anything about all the other cases. IMHO either the database should have a stored schema, or it should not. If IndexedDB is going the direction of not having a stored schema, then the designers should have the confidence in their decision to stick with it and at least produce something with a consistent approach to the problem. 2) making things easy for the user - for me a simpler more predictable API is better for the user. Having a function stored inside the database is bad, because you cannot see what function might be stored in there... We could let you query the stored function. Why would you need to read it. Every time you open the database you would need to check the function is the one you expect. The code would have to contain the function so it can compare it with the one in the DB and update it if necessary. If the code contains the function there are two copies of the function, one in the database and one in the code? which one is correct? which one is it using? So sometimes you will write the new function to the database, and sometimes you will not? More paths to test in code coverage, more complexity. Its simpler to just always set the function when opening the database. it might be a function from a previous version of the code and cause all sorts of strange bugs (which will only affect certain users with a certain version of the function stored in their DB). It will cause *much* less strange bugs than if you have one index that used two different collations, which is the alternative possibility. If the function is stored, the worst case will be that the collation function is out of date. In practice, authors will mostly want to use established collation functions like UCA and won't mind if they're out of date. They'll also only very rarely have occasion to deliberately change the function. As I said, you will end up querying the function to see if it is the one you want to use, if you do that you may as well set it every time. Thinking about this a bit more. If you change the collation function you need to re-sort the
Re: [IndexedDB] Closing on bug 9903 (collations)
On 6 May 2011 00:22, Aryeh Gregor simetrical+...@gmail.com wrote: On Thu, May 5, 2011 at 2:12 AM, Keean Schupke ke...@fry-it.com wrote: What if the new version uses the same property name for a different thing? Yes, obviously it's going to be possible for code changes to cause hard-to-catch bugs due to not updating the database correctly. We don't have to add more cases where that's possible than necessary, without good reason. Maybe there's good reason here, but the added potential for error can't be neglected as a cost. I have seen many bugs in real databases due to stored procedures. Why would you need to read it. Every time you open the database you would need to check the function is the one you expect. Not if you never intend to change it, or don't care if it's outdated. I expect this to be the most common case. People don't change the language setting in an application? Consider the case of someone using CLDR-tailored UCA and a new version comes out. You want to use the newest version for new indexes, if multiple versions are available, but there's no pressing need to automatically update existing indexes. The old version is almost certainly good enough, unless your users use obscure languages. So in my scheme, you can just update the function in your code and do nothing else. In your scheme, you'd have to either stick to the old version across the board, or include both versions in your code indefinitely and include out-of-band logic to choose between them, or write a script that rebuilds the whole index on update (which would take a long time for a large index). At least then the logic to chose between collations is visible in the code, rather than hidden. This is all about transparency and making sure the programmer has control of what is happening, rather than locking them into limiting patterns, and giving them the ability to see exactly what the code will do by reading and code-reviewing it. With a stored procedure, what happens when a function you call (that is not stored) changes? The only way to be sure is to run a validation check in the index (run from beginning to end checking the order is consistent with the comparison function). That is the same whether you use stores procedures or not. The code would have to contain the function so it can compare it with the one in the DB and update it if necessary. If the code contains the function there are two copies of the function, one in the database and one in the code? which one is correct? which one is it using? So sometimes you will write the new function to the database, and sometimes you will not? More paths to test in code coverage, more complexity. Its simpler to just always set the function when opening the database. If the collation function is stored in the database, then I'd expect setting the function to rebuild the index if the new and old functions differ. This could happen as a background operation, with the existing index still usable (with the old collation function) in the meantime. So if you always wanted collations up-to-date, in my scheme authors could just set the function every time they open the database, as with your scheme. But this could trigger a silent rebuild whenever necessary, so the author doesn't have to worry about it. In your scheme, the author has to do the rebuild himself, and if he gets it wrong, the index will be corrupted. So as I see it, my approach is easier to use across the board. It lets you not update collations on old tables without requiring you to keep track of multiple collation function versions, and it also potentially lets you update collations on old tables to the latest versions with rebuilding done for you in the background. Critically, it does not let you change a sort function without rebuilding, since that will always cause bugs and you never want to do it (to a first approximation). Of course, maybe an initial implementation wouldn't do rebuilds for you, to keep it simple. Then the collation function would be immutable after index creation, so you'd still have to do rebuilds yourself. But it would still be easier and safer: the old index will still work in the interim even if you don't have the old version of your collation function around, and you can't mess up and get a corrupted index. Thinking about this a bit more. If you change the collation function you need to re-sort the index to make sure it will work (and avoid those strange bugs). Storing the function in the DB enables you to compare the function and only change it when you need to, thus optimising the number of re-sorts. That is the _only_ advantage to storing the function - as you still need to check the function stored is the one you expect to guarantee your code will run properly. So with a non-persisted function we need to sort every time we open to make sure the order is correct. And
Re: [IndexedDB] Closing on bug 9903 (collations)
On Thu, May 5, 2011 at 11:36 PM, Keean Schupke ke...@fry-it.com wrote: On 6 May 2011 03:00, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 4, 2011 at 11:12 PM, Keean Schupke ke...@fry-it.com wrote: On 5 May 2011 00:33, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 3, 2011 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think we should do callbacks for the first version of javascript. It gets very messy since we can't rely on that the script function will be returning stable values. The worst that would happen if it didn't return stable values is that sorting would return unpredictable results. Worst is an infinite loop - no return. So the choice here really is between only supporting some form of binary sorting, or supporting a built-in set of collations. Anything else will have to wait for version 2 in my opinion. I think it would be a mistake to try supporting a limited set of natural-language collations. Binary collation is fine for a first version. MySQL only supported binary collation up through version 4, for instance. A good point about MySQL. On Wed, May 4, 2011 at 3:49 AM, Keean Schupke ke...@fry-it.com wrote: I thought only the app that created the db could open it (for security reasons)... so it becomes the app's responsibility to do version control. The comparison function is not going to change by itself - someone has to go into the code and change it, when they do that they should up the revision of the database, if that change is incompatible. Why should we let such a pitfall exist if we can just store the function and avoid the issue? I don't see it as a pitfall, it is an has the advantage of transparency. There is exactly the same problem with object properties. If the app changes to expect a new property on all objects stored, then the app has to correctly deal with the update. If a requested property doesn't exist, I assume the API will fail immediately with a clear error code. It will not fail silently and mysteriously with no error code. (Again, I haven't looked at it closely, or tried to use it.) What if the new version uses the same property name for a different thing? For example in V1 'Employer' is a string name, and in V2 'Employer' is a reference to another object. You may say 'you should change the column name'? Right thats just the same as me saying you should change the DB version number when you change the collation algorithm. Its the same thing. People seem to be making a big fuss about having a non-persisted collation function defined in user code, when many many things require the code to have the correct model of the data stored in the database to work properly. It seems illogical to make a special case for this function, and not do anything about all the other cases. IMHO either the database should have a stored schema, or it should not. If IndexedDB is going the direction of not having a stored schema, then the designers should have the confidence in their decision to stick with it and at least produce something with a consistent approach to the problem. 2) making things easy for the user - for me a simpler more predictable API is better for the user. Having a function stored inside the database is bad, because you cannot see what function might be stored in there... We could let you query the stored function. Why would you need to read it. Every time you open the database you would need to check the function is the one you expect. The code would have to contain the function so it can compare it with the one in the DB and update it if necessary. If the code contains the function there are two copies of the function, one in the database and one in the code? which one is correct? which one is it using? So sometimes you will write the new function to the database, and sometimes you will not? More paths to test in code coverage, more complexity. Its simpler to just always set the function when opening the database. it might be a function from a previous version of the code and cause all sorts of strange bugs (which will only affect certain users with a certain version of the function stored in their DB). It will cause *much* less strange bugs than if you have one index that used two different collations, which is the alternative possibility. If the function is stored, the worst case will be that the collation function is out of date. In practice, authors will mostly want to use established collation functions like UCA and won't mind if they're out of date. They'll also only very rarely have occasion to deliberately change the function. As I said, you will end up querying the function to see if it is the one you want to use, if you do that you may as well set it every time.
[WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
Hi, WebIDL currently specifies in the ECMAScript to IDL type mapping [1] that null stringifies to null by default, unless otherwise specified with [TreatNullAs=EmptyString]. This definition matches current selectors-api implementations, which do this conversion for the selectors parameter and this is also the result expected by the current selectors api test suite. However, according to information I got from Anne, and from my own limited testing, this does not seem to be true of other DOMString attributes or properties in other implementations. Recently, in order to resolve a site compatibility issue caused by us stringifying to null for some properties, we made all DOMString APIs consistent in their handling of null, such that they now stringify to an empty string. We believe this is compatible with other implementations for all other attributes and properties that we are aware of. But this fix also had the result of changing the way we handled null in selectors-api, for which we used to stringify as null. I've been informed that Cameron has plans to update WebIDL to make this the default too, but hasn't yet done so. Since Selectors API is defined to use the default behaviour as specified by WebIDL, and if and when WebIDL gets updated, then it also means that the Selectors API implementations in Gecko, WebKit and IE will also need to be updated again and I will need to update the test suite. In Gecko's case, this means reverting back to the behaviour they had shipped in Firefox 3.6, so it's unlikely that reverting this will result in any web compatibility issues. [1] http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [IndexedDB] Closing on bug 9903 (collations)
On 6 May 2011 10:18, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 5, 2011 at 11:36 PM, Keean Schupke ke...@fry-it.com wrote: On 6 May 2011 03:00, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 4, 2011 at 11:12 PM, Keean Schupke ke...@fry-it.com wrote: On 5 May 2011 00:33, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 3, 2011 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think we should do callbacks for the first version of javascript. It gets very messy since we can't rely on that the script function will be returning stable values. The worst that would happen if it didn't return stable values is that sorting would return unpredictable results. Worst is an infinite loop - no return. So the choice here really is between only supporting some form of binary sorting, or supporting a built-in set of collations. Anything else will have to wait for version 2 in my opinion. I think it would be a mistake to try supporting a limited set of natural-language collations. Binary collation is fine for a first version. MySQL only supported binary collation up through version 4, for instance. A good point about MySQL. On Wed, May 4, 2011 at 3:49 AM, Keean Schupke ke...@fry-it.com wrote: I thought only the app that created the db could open it (for security reasons)... so it becomes the app's responsibility to do version control. The comparison function is not going to change by itself - someone has to go into the code and change it, when they do that they should up the revision of the database, if that change is incompatible. Why should we let such a pitfall exist if we can just store the function and avoid the issue? I don't see it as a pitfall, it is an has the advantage of transparency. There is exactly the same problem with object properties. If the app changes to expect a new property on all objects stored, then the app has to correctly deal with the update. If a requested property doesn't exist, I assume the API will fail immediately with a clear error code. It will not fail silently and mysteriously with no error code. (Again, I haven't looked at it closely, or tried to use it.) What if the new version uses the same property name for a different thing? For example in V1 'Employer' is a string name, and in V2 'Employer' is a reference to another object. You may say 'you should change the column name'? Right thats just the same as me saying you should change the DB version number when you change the collation algorithm. Its the same thing. People seem to be making a big fuss about having a non-persisted collation function defined in user code, when many many things require the code to have the correct model of the data stored in the database to work properly. It seems illogical to make a special case for this function, and not do anything about all the other cases. IMHO either the database should have a stored schema, or it should not. If IndexedDB is going the direction of not having a stored schema, then the designers should have the confidence in their decision to stick with it and at least produce something with a consistent approach to the problem. 2) making things easy for the user - for me a simpler more predictable API is better for the user. Having a function stored inside the database is bad, because you cannot see what function might be stored in there... We could let you query the stored function. Why would you need to read it. Every time you open the database you would need to check the function is the one you expect. The code would have to contain the function so it can compare it with the one in the DB and update it if necessary. If the code contains the function there are two copies of the function, one in the database and one in the code? which one is correct? which one is it using? So sometimes you will write the new function to the database, and sometimes you will not? More paths to test in code coverage, more complexity. Its simpler to just always set the function when opening the database. it might be a function from a previous version of the code and cause all sorts of strange bugs (which will only affect certain users with a certain version of the function stored in their DB). It will cause *much* less strange bugs than if you have one index that used two different collations, which is the alternative possibility. If the function is stored, the worst case will be that the collation function is out of date. In practice, authors will mostly want to use established collation functions like UCA and won't mind if they're out of date. They'll also only very rarely
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, May 6, 2011 at 4:09 AM, Keean Schupke ke...@fry-it.com wrote: On 6 May 2011 10:18, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 5, 2011 at 11:36 PM, Keean Schupke ke...@fry-it.com wrote: On 6 May 2011 03:00, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 4, 2011 at 11:12 PM, Keean Schupke ke...@fry-it.com wrote: On 5 May 2011 00:33, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, May 3, 2011 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think we should do callbacks for the first version of javascript. It gets very messy since we can't rely on that the script function will be returning stable values. The worst that would happen if it didn't return stable values is that sorting would return unpredictable results. Worst is an infinite loop - no return. So the choice here really is between only supporting some form of binary sorting, or supporting a built-in set of collations. Anything else will have to wait for version 2 in my opinion. I think it would be a mistake to try supporting a limited set of natural-language collations. Binary collation is fine for a first version. MySQL only supported binary collation up through version 4, for instance. A good point about MySQL. On Wed, May 4, 2011 at 3:49 AM, Keean Schupke ke...@fry-it.com wrote: I thought only the app that created the db could open it (for security reasons)... so it becomes the app's responsibility to do version control. The comparison function is not going to change by itself - someone has to go into the code and change it, when they do that they should up the revision of the database, if that change is incompatible. Why should we let such a pitfall exist if we can just store the function and avoid the issue? I don't see it as a pitfall, it is an has the advantage of transparency. There is exactly the same problem with object properties. If the app changes to expect a new property on all objects stored, then the app has to correctly deal with the update. If a requested property doesn't exist, I assume the API will fail immediately with a clear error code. It will not fail silently and mysteriously with no error code. (Again, I haven't looked at it closely, or tried to use it.) What if the new version uses the same property name for a different thing? For example in V1 'Employer' is a string name, and in V2 'Employer' is a reference to another object. You may say 'you should change the column name'? Right thats just the same as me saying you should change the DB version number when you change the collation algorithm. Its the same thing. People seem to be making a big fuss about having a non-persisted collation function defined in user code, when many many things require the code to have the correct model of the data stored in the database to work properly. It seems illogical to make a special case for this function, and not do anything about all the other cases. IMHO either the database should have a stored schema, or it should not. If IndexedDB is going the direction of not having a stored schema, then the designers should have the confidence in their decision to stick with it and at least produce something with a consistent approach to the problem. 2) making things easy for the user - for me a simpler more predictable API is better for the user. Having a function stored inside the database is bad, because you cannot see what function might be stored in there... We could let you query the stored function. Why would you need to read it. Every time you open the database you would need to check the function is the one you expect. The code would have to contain the function so it can compare it with the one in the DB and update it if necessary. If the code contains the function there are two copies of the function, one in the database and one in the code? which one is correct? which one is it using? So sometimes you will write the new function to the database, and sometimes you will not? More paths to test in code coverage, more complexity. Its simpler to just always set the function when opening the database. it might be a function from a previous version of the code and cause all sorts of strange bugs (which will only affect certain users with a certain version of the function stored in their DB). It will cause *much* less strange bugs than if you have one index that used two different collations, which is the alternative possibility. If the function is stored, the worst case will be that the collation function is out of date. In practice, authors will mostly
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Thu, May 5, 2011 at 3:16 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, May 5, 2011 at 3:43 AM, timeless timel...@gmail.com wrote: My argument is that we should favor: 'case preserving' + 'case folding' + 'case insensitivity'. The virtual file system is going to be something which is mostly controlled by the web app, so there should be minimal harm in telling it that there's already a file with a given name -- it can load the file, review its contents, and try to decide that it should suggest the user use a more distinct name. You're thinking of this only in terms of one narrow, and in my opinion minor, use case: letting the user click save and enter a filename. I'm not actually very interested in that case. (It's minor because a user saving a file usually doesn't want to do so to a virtualized, sandboxed filesystem that he can't access directly. That's the non-sandboxed use case; we're talking about the sandboxed case here.) Much more important is bulk saving data, such as saving large amounts of downloaded data for a game. Consider the case where a user is trying to build a web site, where they might have resources which are accessible via another resource (e.g. a web page). I'd much rather that we not make it easy for users to have Hi, hi, Hï, Hı as distinct files, I don't think they're well served by doing this. If someone gets a collision then something should automatically pick or ask for a different name, this might in rare cases be the user, but on average it'll just be the code itself picking something like hi_1, which will be fine. The proposal is case preserving, so if the file starts as Hı, that's how it'd be returned via any enumeration or shown to the user. It just means that if someone tries to stick an English Hi file into the same place they'll be told to pick a new name. I do not think that short names with colliding cases are better than forcing something (probably a program) to pick better (yes, longer) names which do not collide. Yes, I'm asking to impose a constraint, it means that a game developer can't be annoying and use each of Hi, hi, Hï, and Hı as distinct file names. It's a design constraint, I do not think that a game developer will suffer because of this constraint. And before people complain that I've never had a use for dotless i and can't have sympathy for people who do I've been to İstanbul and have entire photo albums for it (including Topkapı Palace). I also used to work for Nokia (Nokia's history involves a phone which didn't support dotless i's, the result was a miscommunication and at least one stabbing). If file names are going to be generated programmatically, then a constraint that says case preserving, case folding, case insensitive should not be a significant hazard for anyone. It's a serious problem if this isn't interoperable. If filenames are case-insensitive and honor the locale, then people are going to save files as IMAGE.JPG and access them as image.jpg, and it'll work everywhere except on Turkish systems. This point has no merit. Eric's proposal says let's support things which won't work on FAT anyway. As such, anything which tries to serialize to fat and have the resulting content work would have to apply a filter -- just as save as web page complete munges things today.
[Web Sockets] Bug in Web Sockets API WebIDL
Hi, The WebIDL declaration under The WebSocket interface in http://dev.w3.org/html5/websockets/ has a minor bug. It doesn't use the proper syntax for extended attributes: it does [A][B] where the WebIDL grammar is [A,B] in [Constructor(in DOMString url, in optional DOMString protocols)] [Constructor(in DOMString url, in optional DOMString[] protocols)] (found with the WebIDL checker at http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org% 2Fhtml5%2Fwebsockets%2Finput=output=html ) HTH, Dom
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 5/6/11 6:10 AM, Lachlan Hunt wrote: This definition matches current selectors-api implementations, which do this conversion for the selectors parameter and this is also the result expected by the current selectors api test suite. However, according to information I got from Anne, and from my own limited testing, this does not seem to be true of other DOMString attributes or properties in other implementations. It really depends on the case, actually. There has been a good bit of past discussion on this topic that you may want to read. Unfortunately, I don't remember whether that discussion was here, on public-html, on whatwg, or public-webapi, or public-script-coord. Recently, in order to resolve a site compatibility issue caused by us stringifying to null for some properties, we made all DOMString APIs consistent in their handling of null, such that they now stringify to an empty string. We believe this is compatible with other implementations for all other attributes and properties that we are aware of. document.write(null) will write null in Chrome and Gecko (but not Safari). You may want to check IE as well. There are various other cases that have this behavior. In Gecko, anything that goes through JS_ValueToString (instead of default XPConnect argument conversion that converts null to a void empt) will do this. This is unfortunately not particularly consistent. Furthermore, some IDL in Gecko explicitly treats null as null. In addition to the selector API, there's createHTMLDocument, all sorts of stuff on DOMTokenList, .text on HTMLAnchorElement, document.write/writeln, .wrap on HTMLTextAreaElement. So now you're aware of some properties where this is not the case... ;) I've been informed that Cameron has plans to update WebIDL to make this the default too, but hasn't yet done so. Oh, interesting. I'd either missed that or forgotten it... I don't have a problem with this change per se, but note that it will change querySelector(null) from silently doing probably the wrong thing to throwing. I do think it should be safe, though. -Boris
Re: [IndexedDB] Closing on bug 9903 (collations)
On Fri, May 6, 2011 at 2:32 AM, Jonas Sicking jo...@sicking.cc wrote: I'm not worried about crashes or security issues, but I am worried about performance. Not only is it the overhead of crossing from C++ into JS, but also the fact that the C++ code has to go through extra pains to ensure that the world around it still makes sense by the time you come back from the JS callback. For example the callback could have deleted all IndexedDB databases and navigated to a new page. So every time you get back from JS you have to spend a bunch of time rechecking all the state that you were holding in your function implementation. I think that a stored procedure could be considered as a compiled version of a serialized function. i.e. something which loses its scope chain, and which loses access to its parent object. If it loses access to its scope chain which includes the interesting globals, it will no longer have access to fun things like DOM objects, roughly like DOMWorkers but with even less exciting objects available. I'd hope that a jit should be able to do a fairly reasonable job of optimizing such a function given these constraints. The resulting keys could be stored with the database, so you don't have to recalculate them while sorting, only during insertion or if the sort key function is changed. All of this is totally doable. It's not even particularly hard. But it costs performance.
Re: [IndexedDB] Closing on bug 9903 (collations)
On Thu, May 5, 2011 at 10:00 PM, Jonas Sicking jo...@sicking.cc wrote: We have already decided that we don't want to take on the complexity that comes with supporting changing collations on existing data. In particular it becomes very unclear what to do with data that is no longer unique under the new collation. This is only an issue for unique indexes. In MySQL, if you alter a table such that a uniqueness constraint is violated, it will abort with an error as soon as it detects the problem, not changing the table. But if you're using a non-binary collation function, you rarely want a unique index anyway. Still, I don't think this is needed for a first implementation of collations. It's something to support at some future date. I think ultimately we simply seem to disagree here. I think that supporting a standard set of collations is going to solve more than 80% of the use cases (which is a good rule of thumb for these things) for version 1 as well as is easier on users and so something we'll ultimately will want to add anyway. Thus adding it now won't be painting us in a corner and it solves the majority of use cases. If I understand you correctly you don't think that it solves the majority of use cases and you think that it adds API which is bad and that we should never add. Is this a correct assessment? For my part, I agree that supporting a high-quality, comprehensive, standard set of collations, such as UCA with CLDR tailoring, is going to solve much more than 80% of the use-cases. However, 1) Versioning is a possible issue if we want full interop, since CLDR changes often. If browsers can't update the collation of existing indexes, they'll be forced to either stick to one version of CLDR forever, or carry around multiple CLDR version implementations to account for both old and new indexes. Moreover, if browsers do ever update their CLDR version, we'll have different collations going by the same name in different browsers. One way to work around this is to specify for a first pass that browsers must implement some specific CLDR version, like the latest at the time the standard is published, and then just not update it for some indefinite period. 2) If there's going to be collation support in any version, it should be full-fledged UCA, not anything less. Better to push off collation support entirely to a future version than to have some simplified or undefined collation support that will have to be maintained forever. So if possible, support for all CLDR locales would be great; failing that, support for just untailored UCA; failing that, binary collation only. Much better to allow binary collation only than to not define the collation behavior. 3) Allowing users to specify a collation function is not needed in a first or second draft, but could be a useful feature for the future, so it would be worthwhile to at least keep that in mind when defining the API. As long as the API could be later extended to support custom functions without too much trouble, that should be enough for now IMO. I'm sure there are more important things to worry about. (Custom collation functions can be useful for things other than natural language. For instance, http://en.wikipedia.org/wiki/Special:LinkSearch lets you search external links on Wikipedia by prefix. It supports searching for things like *wikipedia.org, which will actually match a domain of ^.*wikipedia.org$ with any path. This works by having an extra field in the externallinks table containing the URL with domain names reversed, like http://org.wikipedia.en./wiki/ instead of http://en.wikipedia.org/wiki/, and this extra field is then indexed. This is a waste of space, since we store the URLs twice. In PostgreSQL we could instead define an index based on a function without having to create an extra column. But as this example illustrates, it's not essential functionality -- you can always add a redundant column.) On Fri, May 6, 2011 at 5:18 AM, Jonas Sicking jo...@sicking.cc wrote: Based on that, my conclusion is that we should go with what Pablo is proposing. And I think we should do it for v1. If I understand correctly, Pablo's proposal is that the author be allowed to specify a locale, and the browser can collate in some undefined way based on that locale. That sounds like a really bad idea for interop. If non-binary collation is supported in a first version, it should be either 1) Two choices, binary or UCA 6.0.0. (AFAIK, UCA gives fairly good results for most languages even without tailoring, so it might be just fine for v1. It's vastly better than binary, for sure.) 2) In addition to binary and UCA 6.0.0, allow UCA 6.0.0 tailored by any of the locales defined by CLDR 1.9.1. There also needs to be some thought put into how to handle version updates, since browsers cannot update their UCA or CLDR implementation without rebuilding all existing indexes that used it (unless they keep the old implementation
Re: [File API: FileSystem] Path restrictions and case-sensitivity
On Fri, May 6, 2011 at 9:38 AM, timeless timel...@gmail.com wrote: Consider the case where a user is trying to build a web site, where they might have resources which are accessible via another resource (e.g. a web page). I'd much rather that we not make it easy for users to have Hi, hi, Hï, Hı as distinct files, I don't think they're well served by doing this. If someone gets a collision then something should automatically pick or ask for a different name, this might in rare cases be the user, but on average it'll just be the code itself picking something like hi_1, which will be fine. This can be solved at the application layer in applications that want it, without baking it into the filesystem API. It's a serious problem if this isn't interoperable. If filenames are case-insensitive and honor the locale, then people are going to save files as IMAGE.JPG and access them as image.jpg, and it'll work everywhere except on Turkish systems. This point has no merit. Eric's proposal says let's support things which won't work on FAT anyway. As such, anything which tries to serialize to fat and have the resulting content work would have to apply a filter -- just as save as web page complete munges things today. I don't know what you're talking about. We're not talking about serializing to FAT, we're talking about case-sensitivity within virtualized filenames. Again, if filenames are case-insensitive, then the API will work differently on a Turkish system than other systems, as I described, in a way that's guaranteed to cause interop failures. This point stands. -- Glenn Maynard
[Bug 12628] New: Web Storage feedback form doesn't work
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12628 Summary: Web Storage feedback form doesn't work Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: simetrical+w3c...@gmail.com QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org When I try to submit anything in the feedback form at http://dev.w3.org/html5/webstorage/, I get the following plaintext message: Because of how we filter for spam, you need to enable JavaScript to use this form, sorry. Alternatively, you can file the bug directly in Bugzilla yourself: http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG I have JavaScript enabled. The filer of bug 12620 also ran into the same problem. Something broken? -- 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.
[Bug 12620] 5MB isn't enough
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12620
Aryeh Gregor simetrical+w3c...@gmail.com changed:
What|Removed |Added
CC||i...@hixie.ch,
||public-webapps@w3.org
Component|HTML5 spec (editor: Ian |Web Storage (editor: Ian
|Hickson)|Hickson)
Product|HTML WG |WebAppsWG
QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org
--- Comment #3 from Aryeh Gregor simetrical+w3c...@gmail.com 2011-05-06
19:12:29 UTC ---
(In reply to comment #2)
Just as an FYI, i posted this here because the form on the Web Storage spec
doesnt work. It says I don't have JS enabled, which obviously, I do. It then
sent me here... it was a feedback on the disk space section. I can post it
elsewhere, I just figured this was the kind of feedback you were looking
for...? If not, what kind of info are you looking for in those forms if its
not
about the spec? Not at all trying to be sarcastic or an ass, actually curious.
Yeah, it seems to be broken. I filed bug 12628 on it. This is good enough,
anyway. The component is wrong, but Ian is the editor of both specs, so it
doesn't matter much. I'll change it to the right component for tidiness.
We're looking for feedback on the spec, yes. However, a lot of what the spec
says is there for a good reason. There'd be no point in changing the spec to
say a minimum of 20 MB if browsers didn't want to go along. The 5 MB limit was
probably the result of considerable discussion. It's enough for basic usage
without risking using up much of the user's disk. Individual browsers can
supply more than the 5 MB requirement, much more if they want. But they're not
likely to all have a much higher limit all the time, because it might use up
too much disk space over time, since localStorage data isn't supposed to be
deleted if possible.
There wasn't any way for you to know this, though. Thanks for the feedback
anyway. The editor will get around to officially responding to it at some
point.
Everyone says that it has to be synchronous but I honestly can't find that
anywhere in the spec. It could be async easily and I actually don't understand
why it couldnt?
In JavaScript terms, synchronous APIs are ones where you do something and then
the next line of code doesn't run until the first line is complete. For
instance, if you do
localStorage[foo] = 1;
alert(localStorage[foo]);
then it will alert 1 (if nothing else is modifying localStorage at the same
time, like the same site in another tab). For this to be reliably true, the
first line must completely finish, with the data submitted to at least
temporary storage, before the second line is run. That's what we mean by
synchronous.
An asynchronous API in JavaScript is where you register an event handler. For
instance, code similar to the above in IndexedDB would be something like . . .
well, I won't try to replicate it, too complicated. But this should give the
basic idea. If store has been initialized to an object store:
store.add({foo: 1}).onsuccess = function(event) {
alert(foo has been set to 1);
}
alert(Some other code);
What this does is call store.add() to do the actual adding of the new value.
That does nothing except return an IDBRequest object immediately. The code
sets the onsuccess property of the object to a function that will be fired when
the add() operation is successful. Then it does nothing else at present, so it
alerts Some other code. When the add() is successful, the browser queues a
success event to fire at the object the next time it needs to run a task. Then
that alerts foo has been set to 1.
The key thing here is that if it takes a while to do reads or writes or such,
script doesn't stop running. The event just won't fire for a while.
JavaScript in browsers is single-threaded, so if the browser gets stuck
executing a particular line, all script has to freeze. This typically means
the whole page freezes. With purely asynchronous APIs, nothing will freeze
even if some event takes a while.
Also, yes, obviously allowing 1GB or unlimited data on all sites wouldn't
work,
but im just saying give the choice to the user. If, for example, photoshop.com
needed 10GBs of data I would give it to them as I need it for the site and I
know what its being used for. Now, if i go to some random site after googling
something and it asks to store that much I would say no. I dont see what the
issue is if its the user making the choice.
This is a possibly valid argument, but what the specification says isn't likely
to change what browsers do here. For open-source browsers like Firefox or
Chromium, you can try asking on a relevant discussion list. Generally,
browsers prefer not to ask the
Re: Model-driven Views
Thanks everyone for your consideration. It sounds like the group wants to proceed by looking first at missing primitives. Maciej is right that one of them is the ability to declare inert DOM structures, but my feeling is that it's probably best to start with the central problem: -There's no way to observe mutations to JS objects. Current approaches resort to a number of hacks which create really terrible artifacts in application code. The ECMA Script Proxy mechanism may be the best starting point, but there's a related problem with timing that isn't addressed. I'll start a thread shortly on this problem detailing our best understanding, and make an attempt to loop in library authors to get their view. On Thu, Apr 28, 2011 at 2:02 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2011, at 6:46 PM, Rafael Weinstein wrote: What do you think? - Is this something you'd like to be implemented in the browsers, Yes. and if yes, why? What would be the reasons to not just use script libraries (like your prototype). FAQ item also coming for this. Having heard Rafael's spiel for this previously, I believe there are some things that templating engines want to do, which are hard to do efficiently and conveniently using the existing Web platform. However, I think it would be better to add primitives to the Web platform that could be used by the many templating libraries that already exist, at least as a first step: - There is a lot of code built using many of the existing templating solutions. If we provide primitives that let those libraries become more efficient, that is a greater immediate payoff than creating a new templating system, where Web apps would have to be rewritten to take advantage. - It seems somewhat hubristic to assume that a newly invented templating library is so superior to all the already existing solutions that we should encode its particular design choices into the Web platform immediately. - This new templating library doesn't have enough real apps built on it yet to know if it is a good solution to author problems. - Creating APIs is best done incrementally. API is forever, on the Web. - Looking at the history of querySelector(), I come to the following conclusion: when there are already a lot of library-based solutions to a problem, the best approach is to provide technology that can be used inside those libraries to improve them; this is more valuable than creating an API with a primary goal of direct use. querySelector gets used a lot more via popular JavaScript libraries than directly, and should have paid more attention to that use case in the first place. Perhaps there are novel arguments that will dissuade me from this line of thinking, but these are my tentative thoughts. Regards, Maciej
Re: Model-driven Views
On 5/6/11, Rafael Weinstein rafa...@google.com wrote: Thanks everyone for your consideration. It sounds like the group wants to proceed by looking first at missing primitives. Missing primitives? What do you mean? -- Garrett
Re: paste events and HTML support - interest in exposing a DOM tree?
On Tue, May 3, 2011 at 3:20 AM, Hallvord R. M. Steen hallv...@opera.comwrote: On Tue, 03 May 2011 07:10:10 +0900, João Eiras joao.ei...@gmail.com wrote: event.clipboardData.getDocumentFragment() which would return a parsed and when applicable sanitized view of any markup the implementation supports from the clipboard. This is already covered by doing x=createElement;x.innerHTML=foo;traverse x Of course it is. The point was simply to see if there was interest in possibly optimising away an extra serialize-parse roundtrip, if developers feel it would be more convenient to get the DOM right away rather than the markup. This sounds good to me. There are good use-cases and it I believe it would be fairly straightforward to implement. What would getDocumentFragment do if there is no text/html content on the clipboard? I'm OK with saying it just returns null or undefined. Ojan
[Bug 12620] 5MB isn't enough
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12620 Oscar Godson oscargod...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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.
