Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam
Re: Steps to creating a browser standard for the moz-icon:// scheme
Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre.
XQuery WG Comments on Indexed Database API
Web Applications Working Group, The XQuery working group have asked me to submit the following comments on their behalf, in review of Indexed Database API (Editor's Draft 26 January 2010): 1) This document does not seem to have any overlap with the XQuery specifications themselves. 2) The API specified in this document looks entirely suitable for implementing an XQuery database on top of, if that was your objective. John Snelson -- John Snelson, Oracle Corporationhttp://snelson.org.uk/john Berkeley DB XML:http://oracle.com/database/berkeley-db/xml XQilla: http://xqilla.sourceforge.net
Re: File API: Blob and underlying file changes.
On Sun, Jan 24, 2010 at 8:04 AM, Juan Lanus juan.la...@gmail.com wrote: ** Locking What's wrong with file locking? Rob O'Callahan answered that: One problem is that mandatory locking is not supported on Mac or most Linux installs. Quite right Bob. But still the lock is the way to go. At least as of today. HTML5 might be mainstream for the next 10 years, starting rather soon. In the meanwhile OSs will also evolve, in a way that we can't tell now. But if there are common issues, like this one, somebody will come up with a smart solution maybe soon. For example feeding an image of the file as of the instant it was opened (like relational databases do to provide stable queries) by keeping a temporary map to the original disk segments that comprised the file before it was changed. For example Apple is encouraging advisory locks http://developer.apple.com/mac/library/technotes/tn/tn2037.html#OSSolutions asking developers to design in an environment-aware mood. Maybe now that I think it a bit more, specifying that the UA should get a lock is telling HOW to do things, while the use cases practice teaches us that at the requirements level one should say WHAT to do. What if the specification only said that the UA has to do its best to get an integral copy of the input file, or else after doing whatever it MUST raise an error? This will leave headroom for the UA designers and also is what the specification says now, isn't it? I got scared by the mutating blob solution. -- Juan Lanus
[IndexedDB] Detailed comments for the current draft
These are notes that we collected both from reviewing the spec (editor's draft up to Jan 24th) and from a prototype implementation that we are working on. I didn't realize we had this many notes, otherwise I would have been sending intermediate notes early. Will do so next round. 1. Keys and sorting a. 3.1.1: it would seem that having also date/time values as keys would be important and it's a common sorting criteria (e.g. as part of a composite primary key or in general as an index key). b. 3.1.1: similarly, sorting on number in general (not just integers/longs) would be important (e.g. price lists, scores, etc.) c. 3.1.1: cross type sorting and sorting of long values are clear. Sorting of strings however needs more elaboration. In particular, which collation do we use? Does the user or developer get to choose a collation? If we pick up a collation from the environment (e.g. the OS), if the collation changes we'd have to re-index all the databases. d. 3.1.3: spec reads …key path must be the name of an enumerated property…; how about composite keys (would make the related APIs take a DOMString or DOMStringList) 2. Values a. 3.1.2: isn't the requirement for structured clones too much? It would mean implementations would have to be able to store and retrieve File objects and such. Would it be more appropriate to say it's just graphs of Javascript primitive objects/values (object, string, number, date, arrays, null)? 3. Object store a. 3.1.3: do we really need in-line + out-of-line keys? Besides the concept-count increase, we wonder whether out-of-line keys would cause trouble to generic libraries, as the values for the keys wouldn't be part of the values iterated when doing a foreach over the table. b. Query processing libraries will need temporary stores, which need temporary names. Should we introduce an API for the creation of temporary stores with transaction lifetime and no name? c. It would be nice to have an estimate row count on each store. This comes at an implementation and runtime cost. Strong opinions? Lacking everything else, this would be the only statistic to base decisions on for a query processor. d. The draft does not touch on how applications would do optimistic concurrency. A common way of doing this is to use a timestamp value that's automatically updated by the system every time someone touches the row. While we don't feel it's a must have, it certainly supports common scenarios. 4. Indexes a. 3.1.4 mentions auto-populated indexes, but then there is no mention of other types. We suggest that we remove this and in the algorithms section describe side-effecting operations as always updating the indexes as well. b. If during insert/update the value of the key is not present (i.e. undefined as opposite to null or a value), is that a failure, does the row not get indexed, or is it indexed as null? Failure would probably cause a lot of trouble to users; the other two have correctness problems. An option is to index them as undefined, but now we have undefined and null as indexable keys. We lean toward this last option. 5. Databases a. Not being able to enumerate database gets in the way of creating good tools and frameworks such as database explorers. What was the motivation for this? Is it security related? b. Clarification on transactions: all database operations that affect the schema (create/remove store/index, setVersion, etc.) as well as data modification operations are assumed to be auto-commit by default, correct? Furthermore, all those operations (both schema and data) can happen within a transaction, including mixing schema and data changes. Does that line up with others' expectations? If so we should find a spot to articulate this explicitly. c. No way to delete a database? It would be reasonable for applications to want to do that and let go of the user data (e.g. a forget me feature in a web site) 6. Transactions a. While we understand the goal of simplifying developers' life with an error-free transactional model, we're not sure if we're making more harm by introducing more concepts into this space. Wouldn't it be better to use regular transactions with a well-known failure mode (e.g. either deadlocks or optimistic concurrency failure on commit)? b.If in auto-commit mode, if two cursors are opened at the same time (e.g. to scan them in an interleaved way), are they in independent transactions simultaneously active in the same connection? 7. Algorithms a. 3.2.2: steps 4 and 5 are inverted in order. b. 3.2.2: when there is a key generator and the store uses in-line keys, should the generated key value be propagated to the original object (in addition to the clone), such that both are in sync after the put operation? c. 3.2.3: step 2, probably editorial mistake? Wouldn't all indexes have a key
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. To gain an interoperability benefit, we would presumably need to define the set of icons available, right? Chromium currently has an internal scheme (chrome://fileicon/path) that it is using for internal HTML pages and Mozilla's moz-icon scheme is already exposed to web content. I am not sure if other browsers have similar schemes for providing icon resources internally. I am working on the Internet Draft for this and will be seeking feedback soon enough. If anyone has any thoughts on security issues, it would be most welcomed as a thorough security analysis is required for the draft. I would recommend not using // in URLs of this scheme unless they have an authority component. It is better for them not to look like a hierarchical URI in that case. Regards, Maciej Thanks. 2010/1/26 Adam Barth w...@adambarth.com On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? I think Pierre-Antoine would like to expose this to web content. Adam -- Pierre.
Re: [IndexedDB] Detailed comments for the current draft
Hi Pablo, Great work and excellent feedback. I will take a little bit of time to digest and respond. Nikunj On Jan 26, 2010, at 12:47 PM, Pablo Castro wrote: These are notes that we collected both from reviewing the spec (editor's draft up to Jan 24th) and from a prototype implementation that we are working on. I didn't realize we had this many notes, otherwise I would have been sending intermediate notes early. Will do so next round. 1. Keys and sorting a. 3.1.1: it would seem that having also date/time values as keys would be important and it's a common sorting criteria (e.g. as part of a composite primary key or in general as an index key). b. 3.1.1: similarly, sorting on number in general (not just integers/longs) would be important (e.g. price lists, scores, etc.) c. 3.1.1: cross type sorting and sorting of long values are clear. Sorting of strings however needs more elaboration. In particular, which collation do we use? Does the user or developer get to choose a collation? If we pick up a collation from the environment (e.g. the OS), if the collation changes we'd have to re- index all the databases. d. 3.1.3: spec reads …key path must be the name of an enumerated property…; how about composite keys (would make the related APIs take a DOMString or DOMStringList) 2. Values a. 3.1.2: isn't the requirement for structured clones too much? It would mean implementations would have to be able to store and retrieve File objects and such. Would it be more appropriate to say it's just graphs of Javascript primitive objects/values (object, string, number, date, arrays, null)? 3. Object store a. 3.1.3: do we really need in-line + out-of-line keys? Besides the concept-count increase, we wonder whether out-of-line keys would cause trouble to generic libraries, as the values for the keys wouldn't be part of the values iterated when doing a foreach over the table. b. Query processing libraries will need temporary stores, which need temporary names. Should we introduce an API for the creation of temporary stores with transaction lifetime and no name? c. It would be nice to have an estimate row count on each store. This comes at an implementation and runtime cost. Strong opinions? Lacking everything else, this would be the only statistic to base decisions on for a query processor. d. The draft does not touch on how applications would do optimistic concurrency. A common way of doing this is to use a timestamp value that's automatically updated by the system every time someone touches the row. While we don't feel it's a must have, it certainly supports common scenarios. 4. Indexes a. 3.1.4 mentions auto-populated indexes, but then there is no mention of other types. We suggest that we remove this and in the algorithms section describe side-effecting operations as always updating the indexes as well. b. If during insert/update the value of the key is not present (i.e. undefined as opposite to null or a value), is that a failure, does the row not get indexed, or is it indexed as null? Failure would probably cause a lot of trouble to users; the other two have correctness problems. An option is to index them as undefined, but now we have undefined and null as indexable keys. We lean toward this last option. 5. Databases a. Not being able to enumerate database gets in the way of creating good tools and frameworks such as database explorers. What was the motivation for this? Is it security related? b. Clarification on transactions: all database operations that affect the schema (create/remove store/index, setVersion, etc.) as well as data modification operations are assumed to be auto-commit by default, correct? Furthermore, all those operations (both schema and data) can happen within a transaction, including mixing schema and data changes. Does that line up with others' expectations? If so we should find a spot to articulate this explicitly. c. No way to delete a database? It would be reasonable for applications to want to do that and let go of the user data (e.g. a forget me feature in a web site) 6. Transactions a. While we understand the goal of simplifying developers' life with an error-free transactional model, we're not sure if we're making more harm by introducing more concepts into this space. Wouldn't it be better to use regular transactions with a well-known failure mode (e.g. either deadlocks or optimistic concurrency failure on commit)? b.If in auto-commit mode, if two cursors are opened at the same time (e.g. to scan them in an interleaved way), are they in independent transactions simultaneously active in the same connection? 7. Algorithms a. 3.2.2: steps 4 and 5 are inverted in order. b. 3.2.2: when there is a key generator and the store uses in- line keys,
[FastMutation] Updated Proposal on the DOM L3 Events Wiki
Based on the last round of feedback [1], I've updated the proposal for Selector-based mutation events (which I keep calling fast mutation events for some reason...). Doug, I'm sure you're hard at work on a better acronym... In this edition, I expanded the background sections and enumerated many of the usage scenarios, relying heavily on previous email threads and discussions to summarize points. For completeness I also added Jonas' original proposal so that the two could be compared side-by-side. The proposals are very different--each has pros and cons, and I hope that through constructive discussions we can arrive at a unified proposal that will work for most (or all) scenarios. So, please go read it and let me know what you think: http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events_v2_%28needs_a_better_name%29 Doug, consider this the kick-off for W3C-ifying this proposal. [1] http://lists.w3.org/Archives/Public/www-dom/2009OctDec/0140.html
Re: Interface names in IndexedDB (and WebSQLDatabase)
(Are these comments going into someone's queue somewhere, or should I be concerned there was no further response? I ask because I'd kind of like to start checking .idl files into WebKit. :-) On Fri, Jan 22, 2010 at 9:53 AM, Jeremy Orlow jor...@chromium.org wrote: In general, sounds good to me. Note that there already is an IndexedDatabase interface in your spec though. I'd also suggest renaming at least the following: ObjectStore KeyRange Environment DatabaseError At which point, there's not too many interfaces left without the IDB prefix (mostly synchronous variants of these interfaces) so maybe we should just prefix everything? Thanks! J On Fri, Jan 22, 2010 at 8:16 AM, Nikunj Mehta nik...@o-micron.com wrote: On Jan 22, 2010, at 12:01 AM, Jeremy Orlow wrote: The interface names in IndexedDB (and to an extent, WebSQLDatabase) are very generic. Surprisingly, the specs only collide via the Database interface (which is why I bring this up), but I'm concerned that names like Cursor, Transaction, and Index (from IndexedDB) are so generic that they're bound to conflict with other specs down the road. Note that all but 5 interfaces in the WebSQLDatabase spec are prefixed with SQL (for example, SQLTransaction) which helps a lot. It seems as though the remaining could also be prefixed by SQL to solve the problem. That will help. I'm wondering if the majority of the IndexedDB interfaces should also have some prefix (like IDB?) as well since many of its terms are quite generic. I am fine with the following renaming: Database - IndexedDatabase Cursor - IDBCursor Transaction - IDBTransaction Index - IDBIndex Nikunj
Re: File API: Blob and underlying file changes.
On Wed, Jan 27, 2010 at 5:38 AM, Juan Lanus juan.la...@gmail.com wrote: Quite right Bob. But still the lock is the way to go. At least as of today. HTML5 might be mainstream for the next 10 years, starting rather soon. In the meanwhile OSs will also evolve, in a way that we can't tell now. But if there are common issues, like this one, somebody will come up with a smart solution maybe soon. For example feeding an image of the file as of the instant it was opened (like relational databases do to provide stable queries) by keeping a temporary map to the original disk segments that comprised the file before it was changed. For example Apple is encouraging advisory locks http://developer.apple.com/mac/library/technotes/tn/tn2037.html#OSSolutions asking developers to design in an environment-aware mood. In my experience, almost no code uses advisory locking unless it is being explicitly designed for some kind of concurrent usage, i.e., Apple's advice is not being followed. If that's not going to suddenly change --- and I see no evidence it will --- then asking the UA to apply a mandatory lock is asking the UA to do something impossible, which is generally not a good idea. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Interface names in IndexedDB (and WebSQLDatabase)
Hi Jeremy, I have edited the spec to use IDB as the prefix of every interface it defines. Nikunj On Jan 26, 2010, at 6:38 PM, Jeremy Orlow wrote: (Are these comments going into someone's queue somewhere, or should I be concerned there was no further response? I ask because I'd kind of like to start checking .idl files into WebKit. :-) On Fri, Jan 22, 2010 at 9:53 AM, Jeremy Orlow jor...@chromium.org wrote: In general, sounds good to me. Note that there already is an IndexedDatabase interface in your spec though. I'd also suggest renaming at least the following: ObjectStore KeyRange Environment DatabaseError At which point, there's not too many interfaces left without the IDB prefix (mostly synchronous variants of these interfaces) so maybe we should just prefix everything? Thanks! J On Fri, Jan 22, 2010 at 8:16 AM, Nikunj Mehta nik...@o-micron.com wrote: On Jan 22, 2010, at 12:01 AM, Jeremy Orlow wrote: The interface names in IndexedDB (and to an extent, WebSQLDatabase) are very generic. Surprisingly, the specs only collide via the Database interface (which is why I bring this up), but I'm concerned that names like Cursor, Transaction, and Index (from IndexedDB) are so generic that they're bound to conflict with other specs down the road. Note that all but 5 interfaces in the WebSQLDatabase spec are prefixed with SQL (for example, SQLTransaction) which helps a lot. It seems as though the remaining could also be prefixed by SQL to solve the problem. That will help. I'm wondering if the majority of the IndexedDB interfaces should also have some prefix (like IDB?) as well since many of its terms are quite generic. I am fine with the following renaming: Database - IndexedDatabase Cursor - IDBCursor Transaction - IDBTransaction Index - IDBIndex Nikunj
[WebTiming] HTMLElement timing
Folks, Thanks to the much feedback from various developers, the WebTiming specs has undergone some major revision. Timing info has now been extended to page elements and a couple more interesting timing data points are added. The draft is up on http://dev.w3.org/2006/webapi/WebTiming/ Feedback and comments are highly appreciated. cheers, Zhiheng
