Re: Some IndexedDB feedback
Hi all, Sorry to be slow in responding to all the feedback on Indexed DB. As you know, this is now my unpaid work and I am trying my best to respond to comments before the weekend is up. But this is good. Please keep the feedback and early implementation experience coming. On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote: I've started work on implementing the IndexedDB bindings in WebKit as a way to sanity check the API. I figure it's easiest to trickle feedback to this list rather than save it all up for a big thread, but I'm happy to do that if it's preferred. I prefer to get incremental comments unless there is a major hole in the spec and you need time to digest it and prepare a comprehensive proposal Interfaces I've looked at so far: IDBEnvironment IndexedDatabaseRequest IDBRequest IDBDatabaseError IDBDatabaseException First of all, I just wanted to say that I found the event based nature of IndexedDatabaseRequest/IDBRequest fairly cumbersome. Why not just have open take in a onsuccess and onerror callbacks and return an object which has the ready state, an abort method, and maybe an error code? It seems as though the event based API is actually more confusing and artificially limiting (only one open request in flight at a time) than is necessary. Every approach has its pros and cons. More than with other APIs, a database API that is all three - low-level, easy to program, and asynchronous - is not easy to get. I don't know for sure that we can satisfy all three. I am going to take one more crack at this and have this item on my to-do list. I assume that the limitation is only one database _opening_ in flight at once, and not a limitation that you can only have one database open ever? Correct. Only one _in-flight_ request on an object. If we had a DataCache-style API, every synchronous call would return a result, and an asynchronous call would return a promise. It would be more flexible, but no easier to deal with. What is IDBRequest.error when there is no error? null? When would it be reset? The next time you call open? I have clarified this. Any time request is in INITIAL or LOADING state, error is null. It would be reset whenever the request transitions from DONE back to LOADING state. What happens when you call abort and there is no pending open? Is it a no-op? No-op is the correct behavior. Is it really necessary to have a separate IDBDatabaseException and IDBDatabaseError? I know one is technically an exception and one is technically an interface, but it seems a bit silly. Also, it seems as though they both share the same codes, but the codes are only defined in IDBDatabaseException? If so, I'm not sure it's clear enough in the spec. Do you have a Web IDL proposal for this? I would love to be correct and satisfy you. However, I am not an expert in the business of WebIDL. But really, does IndexedDB really need its own error and exception classes? At very least, I know the WebSQLDB spec has a very similar error class. And I suspect there are others, though I didn't immediately find anything looking through the HTML5 spec. XHR defines codes, but no new exceptions. File API has both and a style similar to Indexed Database Maybe these types of interfaces should be specified in parent specs and not duplicated in those that depend on them? I am willing to go with whatever works for everyone. In 3.4.5 probably means to say events rather than callbacks in the first sentence. Yes In 3.4.2, queue is mispelled as aueue. Gotcha That's all I have for now. I've skimmed over the whole spec but only read carefully these sections, so please excuse me if any of my questions can be answered from text elsewhere in the spec. (Though maybe it would be a sign that the relevant sections should be more clear?) Thanks! J
Re: [IndexedDB] Detailed comments for the current draft
On Jan 31, 2010, at 11:33 PM, Nikunj Mehta wrote: d. The current draft fails to format in IE, the script that comes with the page fails with an error I am aware of this and am working with the maintainer of ReSpec.js tool to publish an editor's draft that displays in IE. Would it be OK if this editor's draft that works in IE is made available at an alternate W3C URL? http://dev.w3.org/2006/webapi/WebSimpleDB/post-Overview.html has the current static version, which should work in IE. I will try to keep it updated, not too far behind the default URL.
Re: Some IndexedDB feedback
On Mon, Feb 1, 2010 at 12:02 AM, Nikunj Mehta nik...@o-micron.com wrote: Hi all, Sorry to be slow in responding to all the feedback on Indexed DB. As you know, this is now my unpaid work and I am trying my best to respond to comments before the weekend is up. But this is good. Please keep the feedback and early implementation experience coming. On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote: I've started work on implementing the IndexedDB bindings in WebKit as a way to sanity check the API. I figure it's easiest to trickle feedback to this list rather than save it all up for a big thread, but I'm happy to do that if it's preferred. I prefer to get incremental comments unless there is a major hole in the spec and you need time to digest it and prepare a comprehensive proposal Interfaces I've looked at so far: IDBEnvironment IndexedDatabaseRequest IDBRequest IDBDatabaseError IDBDatabaseException First of all, I just wanted to say that I found the event based nature of IndexedDatabaseRequest/IDBRequest fairly cumbersome. Why not just have open take in a onsuccess and onerror callbacks and return an object which has the ready state, an abort method, and maybe an error code? It seems as though the event based API is actually more confusing and artificially limiting (only one open request in flight at a time) than is necessary. Every approach has its pros and cons. More than with other APIs, a database API that is all three - low-level, easy to program, and asynchronous - is not easy to get. I don't know for sure that we can satisfy all three. I am going to take one more crack at this and have this item on my to-do list. I'll try to think about this as well and offer some suggestions as I gain further experience with the API. I assume that the limitation is only one database _opening_ in flight at once, and not a limitation that you can only have one database open ever? Correct. Only one _in-flight_ request on an object. If we had a DataCache-style API, every synchronous call would return a result, and an asynchronous call would return a promise. It would be more flexible, but no easier to deal with. What is IDBRequest.error when there is no error? null? When would it be reset? The next time you call open? I have clarified this. Any time request is in INITIAL or LOADING state, error is null. It would be reset whenever the request transitions from DONE back to LOADING state. What happens when you call abort and there is no pending open? Is it a no-op? No-op is the correct behavior. Is it really necessary to have a separate IDBDatabaseException and IDBDatabaseError? I know one is technically an exception and one is technically an interface, but it seems a bit silly. Also, it seems as though they both share the same codes, but the codes are only defined in IDBDatabaseException? If so, I'm not sure it's clear enough in the spec. Do you have a Web IDL proposal for this? I would love to be correct and satisfy you. However, I am not an expert in the business of WebIDL. I'm pretty sure you know more WebIDL than me. Maybe there are other experts on the list that can offer some suggestions. But really, does IndexedDB really need its own error and exception classes? At very least, I know the WebSQLDB spec has a very similar error class. And I suspect there are others, though I didn't immediately find anything looking through the HTML5 spec. XHR defines codes, but no new exceptions. File API has both and a style similar to Indexed Database Maybe these types of interfaces should be specified in parent specs and not duplicated in those that depend on them? I am willing to go with whatever works for everyone. Can any spec/IDL experts offer any suggestions here? Thanks again, Nikunj J
Re: [IndexedDB] Detailed comments for the current draft
On Sun, Jan 31, 2010 at 11:33 PM, Nikunj Mehta nik...@o-micron.com wrote: 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). The Web IDL spec does not support a Date/Time data type. Could your use case be supported by storing the underlying time with millisecond precision using an IDL long long type? I am willing to change the spec so that it allows long long instead of long IDL type, which will provide adequate support for Date and time sorting. Can the spec not be augmented? It seems like other specs like WebGL have created their own types. If not, I suppose your suggested change would suffice as well. This does seem like an important use case. b. 3.1.1: similarly, sorting on number in general (not just integers/longs) would be important (e.g. price lists, scores, etc.) I am once again hampered by Web IDL spec. Is it possible to leave this for future versions of the spec? 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. I propose to use Unicode collation algorithm, which was also suggested by Jonas during a conversation. 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) I prefer to leave composite keys to a future version. 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)? Your list leaves out File, Blob, FileList, ImageData, and RegExp types. While I don't feel so strongly about all these types, I believe that support for Blob/File and ImageData will be beneficial to those who work with browsers. Instead of profiling this algorithm, I think it is best to just require the same algorithm. 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. Certainly it is a matter of prioritizing among various requirements. Out-of-line keys enable people to store simple persistent hash maps. I think it would be wrong to require that data be always stored as objects. A library can always elide the availability of out-of-line keys if that poses a problem to its users. 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? Firstly, I think we can leave this safely to a future version. Secondly, my suggestion would be to provide a parameter to the create call to indicate that an object store being created is a transient one, i.e., not backed by durable storage. They could be available across different transactions. If your intention is to not make these object stores unavailable across connections, then we can also offer a connection-specific transient object store. In general, it requires us to introduce the notion of create params, which would simplify the evolution of the API. This is also similar to how Berkeley DB handles various options, not just those related to creation of a Berkeley database. 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. I believe we need to have a general way of estimating the number of records in a cursor once a key range has been specified. Kris Zyp also brings this up in a separate email. I am willing to add an estimateCount attribute to IDBCursor for this. 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
Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Sun, 31 Jan 2010, Sebastian Andersson wrote: On Sat, Jan 30, 2010 at 10:31, Ian Hickson i...@hixie.ch wrote: Right now, today, if I were to expose a WebSocket service on my Dreamhost shared server, I could do so without any trouble. If we used a scheme such as the one described above using a policy file, anyone else also hosting their site on the same server could grant access to my server to their scripts on their page. Whether this is a technical or administrative issue, it's an issue we have to handle today. If you only allow the policy file from being read from a single port How would we do that? IMHO, yes. I understand that security is a tradeoff between risk and reward, but fundamentally, it seems to me that it is far off the risk/reward scale to design a system in such a way that a security problem cannot be fixed when it is discovered. Having the user agent cache the security policy and act on that cached version even after a security problem has been found prevents security problems from being fixed in a timely manner. Sure, it would cause a downtime We should not design our protocol in such a way that a configuration mistake in a security policy can only be fixed by forcing downtime on existing users. With the Web Socket protocol: - Existing services would have to be changed if they should be accessible (with the risk of bugs, duplication of existing access control and logging). This is intentional, to prevent pages from abusing existing services. -- This is a huge total cost and a huge potential for security problems. I think this massively overstates the risks. - Requires all new services to implement the policy mechanism correctly. It's pretty trivial to implement. -- Instead of just having a few correct implementations in the clients (that already have code for origin handling and whose designers hopefully are aware of the problems), each server will have to have it with associated risks of errors. A huge potential for new security problems. Will of course be cheaper and less risky when libraries are available for most languages, but still many more implementations. I don't understand. Why would the servers have it? It's the client that enforces the security policy. - Native clients against a new service would have to use the Web Socket protocol too. If it's a Web Socket subprotocol... then yes. I wouldn't recommend that people use this protocol for designing protocols intended to be used by native clients other than browsers, though obviously that's possible too. -- Adds a little extra cost and risks. Will of course be cheaper and less risky when libraries are available for most languages, but still way more implementations. Than what? I'm confused. Web Socket is really trivial to implement -- the whole point is to make it easy to implement so anyone can do it. It's like CGI, intended for anyone to be able to hack something up quickly. What about someone adding support for Basic authentication in their client, exposing the credentials? I don't understand this point. What does the Web Socket protocol have to do with how you design your subprotocol's authentication? - One can't prevent a client from connecting to a port that it should not be allowed to connect to, but the client can't start communications. No idea what that means. -- Yet another DoS vector, but as you've written, there are others so then it is ok? It's not another DOS vector, it's the same DOS vector. You already have to handle it. If you're safe from DOSes from img (which have been on the Web for 17 years or so now), you're safe from this one. - Can be used for port mapping. No more so than img, or XHR, or script src=, or pretty much any other mechanism in HTML today. -- But as you've written, there are other ways, so then it is acceptable? I'm certainly open to suggestions for avoiding this problem, but short of introducing random delays, I don't see how to fix it. Unless we force a port, which I don't see how we can do, a policy file would have the same problem (just use the policy file to do the port scanning). - Part of the security of the protocol relies on the fact that the clients can't use raw TCP sockets. This is not always true if the client has the flash, java or the Silverlight plugins. What about future plugins or APIs? What about them? -- During a transition phase to html5, I would think that people would simulate the Web Socket API via scriptable flash clients since most users already have it installed, so this would probably become rather common. Someone might also do the same via Silverlight. Actually so far most people have emulated it using XHR. - Makes it simpler to implement authentication and SSO against Web Socket services. Not sure what you mean here. Fundamentally, raw sockets plus a policy file is a completely different approach than Web
Re: [XHR] New api request
On Sun, Jan 31, 2010 at 8:38 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 29 Jan 2010 14:29:23 +0100, Pedro Santos pedros...@gmail.com wrote: Hi, how interest is for you develop new APIs in order to enable a reuse of the XMLHttpRequest objects, without the need to call abort method? No need to ask questions twice :-) At this thread we can point reason to create or not an new api for: restart, reset, clear states, turn new to reuse, the XHR object. I have opened another thread to know from the experts the currents workarounds to get desired results in reutilization with the current api. -- Anne van Kesteren http://annevankesteren.nl/ -- Pedro Henrique Oliveira dos Santos
Re: [XHR2] AnonXMLHttpRequest()
On Mon, 01 Feb 2010 03:45:54 +0100, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jan 31, 2010 at 1:50 PM, Anne van Kesteren ann...@opera.com wrote: I'm not really convinced we need all of http://dev.w3.org/2006/waf/UMP/ to handle the simple use case it is for. I think UMP can be layered on top of CORS by simply letting the origin be a unique identifier and always have the credentials flag be false. A new constructor could be used for XMLHttpRequest -- maybe called AnonXMLHttpRequest() -- to enable this behavior. Since most people in the WG seem to think we should have both UMP and CORS this solution seems much more straightforward and practical. Thoughts? What do you mean by unique identifier? The same as HTML5? I.e. something that results in Origin: null. -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] events for async requests
On Mon, 01 Feb 2010 03:38:08 +0100, Jonas Sicking jo...@sicking.cc wrote: On Sun, Jan 31, 2010 at 5:09 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 16 Dec 2009 20:46:03 +0100, Jonas Sicking jo...@sicking.cc wrote: 1. Update .responseText 2. If readystate is not yet 3, set it to 3 and fire readystatechange This would dispatch readystatechange to often. The specification sides with IE/Opera here rather than WebKit/Gecko. Huh? This would only fire readystatechange for readyState=3 once per request. That doesn't seem too often. My bad. I thought you meant to dispatch readystatechange regardless. 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired within the past 50ms This is already required elsewhere. I suppose I could try to merge the two, would that be useful? The main point of my email was that responseText should never change other than from the main event loop. I.e. doing xhr.responseText == xhr.responseText should always return true. Ok. That is definitely covered now. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] New api request
On Mon, 01 Feb 2010 11:14:44 +0100, Pedro Santos pedros...@gmail.com wrote: At this thread we can point reason to create or not an new api for: restart, reset, clear states, turn new to reuse, the XHR object. I have opened another thread to know from the experts the currents workarounds to get desired results in reutilization with the current api. As you wish. I don't see a reason for a new API given that open() ought to work (though apparently IE currently has a bug). Also, you could just create a new object and let the previous one be garbage collected. -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] events for async requests
On Mon, Feb 1, 2010 at 2:27 AM, Anne van Kesteren ann...@opera.com wrote: 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired within the past 50ms This is already required elsewhere. I suppose I could try to merge the two, would that be useful? The main point of my email was that responseText should never change other than from the main event loop. I.e. doing xhr.responseText == xhr.responseText should always return true. Ok. That is definitely covered now. It is still unclear what the relationship is between responseText being set to a non-empty value, and switching to the LOADING state is. Which happens first (it's somewhat clear that responseText is changed before switching to the LOADING state)? Can responseText ever be non-empty without being in the LOADING state? I.e. do these to actions happen from the same, or from separate, tasks posted to the event loop? / Jonas
Re: [xhr] events for async requests
On Mon, 01 Feb 2010 12:12:18 +0100, Jonas Sicking jo...@sicking.cc wrote: It is still unclear what the relationship is between responseText being set to a non-empty value, and switching to the LOADING state is. Which happens first (it's somewhat clear that responseText is changed before switching to the LOADING state)? The response entity body is updated first. Can responseText ever be non-empty without being in the LOADING state? I.e. do these to actions happen from the same, or from separate, tasks posted to the event loop? The same. I could make this more explicit if you want. -- Anne van Kesteren http://annevankesteren.nl/
Re: Steps to creating a browser standard for the moz-icon:// scheme
Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a thumbnail is not available (or perhaps regardless of whether or not a thumbnail is available) you could get some other image representation that is somehow representative of the file type (e.g. some icon for JPEG files -- this image does not need to be part of the standard, does not need to be consistent across browsers, but should ideally be consistent for all JPEG files you call geticon on within the same UA on the same computer... My $0.02 2010/1/31 Maciej Stachowiak m...@apple.com On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote: 2010/1/29 Ian Fette (イアンフェッティ) ife...@google.com 2010/1/28 Maciej Stachowiak m...@apple.com On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote: It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7 ...) the OS actually does create a pre-computed high quality icon for many files, e.g. images, PDF, Word, Photoshop, It is almost free to get this from the OS, and the OS also has 3 default sizes for it. It would be great to provide access to this if you have a File handle to it. Mac OS X has 5 default sizes and can reasonably efficiently interpolate sizes in between. On the other hand, iPhone OS doesn't have any file icons, or even a really user-visible concept of files. So I'm not sure we can make too many assumptions about what will hold across platforms. Regards, Maciej Sure - there are some platforms where it may not be available (including perhaps winxp?). But it's an interesting idea to expose these if they are available, and if they're not available, then fall back to some default. Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: * Parameter: size * Values: [integer | button | toolbar | toolbarsmall | menu | dialog] * Description: If integer, this is the desired size in square pixels of the icon *Else, use the OS default for the specified keyword context. integer scales the icons to the desired size. I think we'd at least need a few different sizes for a default set of icons. I'm not sure that such icons exist. I don't see a need to standardize anything solely for use by extensions. What we should ask is which icons are useful for Web content, since that is where we have the interoperability constraint. Extensions do not currently interoperate between different browsers, nor is this planned as far as I can tell, so they cannot be the sole use case for any part of a Web standard IMO. Regards, Maciej
Re: [xhr] events for async requests
On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren ann...@opera.com wrote: Can responseText ever be non-empty without being in the LOADING state? I.e. do these to actions happen from the same, or from separate, tasks posted to the event loop? The same. I could make this more explicit if you want. Where in the spec is this defined? I guess my answer is yes, it'd be nice if it was more explicit. :) / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
Yes but in Windows XP they upscale anything over 48x48 I believe. On 1 February 2010 01:24, timeless timel...@gmail.com wrote: 2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm -- Pierre.
Re: [xhr] events for async requests
On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren ann...@opera.com wrote: Can responseText ever be non-empty without being in the LOADING state? I.e. do these to actions happen from the same, or from separate, tasks posted to the event loop? The same. I could make this more explicit if you want. Where in the spec is this defined? I guess my answer is yes, it'd be nice if it was more explicit. :) You haven't even read the specification on this yet? :/ See step 9 under the send() method: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ In particular the two sections flagged with If the asynchronous flag is true. -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] events for async requests
On Mon, Feb 1, 2010 at 4:12 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren ann...@opera.com wrote: Can responseText ever be non-empty without being in the LOADING state? I.e. do these to actions happen from the same, or from separate, tasks posted to the event loop? The same. I could make this more explicit if you want. Where in the spec is this defined? I guess my answer is yes, it'd be nice if it was more explicit. :) You haven't even read the specification on this yet? :/ See step 9 under the send() method: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ In particular the two sections flagged with If the asynchronous flag is true. I have read the spec, but I still don't see where it says that responseText and the state is updated from the same task. Is the idea that every bullet under The same-origin request event rules are as follows is always performed from the same task? But even then the actual updating of the state is not listed in the same set of bullets. / Jonas
Re: Steps to creating a browser standard for the moz-icon:// scheme
So it seems like there is a general consensus that at least some parts of the icon URI scheme are useful and are worth standardizing. One thing I was confused about was the mention of the File object; I initially believed we were referring to http://www.mozilla.org/js/js-file-object.html, however, if I'm not mistaken, I think people actually mean the FileUpload object. I've summarized the issues discussed thus far: *Possible Usage Examples:* # Return the platform icon for the given extension icon:.zip?size=16state=disabled # query form icon:.mp3;16;disabled # short form # Return the platform icon for the specified file URI icon:file:///home/pierre/test.png # Return an icon for a standardized identifier name icon:stock/gtk-go-up?size=menu icon:stock/newtab;32;disabled icon:stock/home;16 icon:stock/refresh;48 *Security risks* - Probing??? - Mozilla has been exposing the moz-icon scheme to the web for years. - Avoiding Cross-domain theft of arbitrary images; machine fingerprinting - Canvas getPixelData and toDataURL API calls - The only issue has been the cross-domain image theft ( http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html) vulnerability in Firefox 2 that has since been resolved with cross-domain checks. - User interaction visual exploit - Gets user to confirm a known pixel is present in the icon image - Very loose exploit; basically tricking a user into providing information about her installed applications - Mozilla allows this exploit - Can retrieve the width and height of an image without security checks. *File URIs in icon scheme* - What are the use cases? - Browser, local html, web sites where files are uploaded by user. - Risk of file system probing?? - Maybe if somehow the web site can acess the image data for an icon. - Can we use an input File object instead? - Idea: Get a magic restricted-use URL for that file's icon from the File object, the same as you can get a URL for the file's contents. - Idea: The File object could give you an icon: URL that specifically identifies that file's icon. - Idea: The File object could give you the data URI for the icon. *Stock Images* - Should we include the stock image option in the specification? - Hard to define a common set of icons (and sizes) across all platforms - Cross platform: save, zoom in/out, print, folder, file, cut, paste, copy, delete, add, ok, cancel, about, info, help, quit, strikethrough, underline, select font, select color, quote, center, left/right align, change font, text-size, list, bold, italic, etc. - E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html - Browser specific: newtab, forward, back, stop, home, refresh, etc. - Possibly find a set of creative common icons that can always be used if the platform does not provide the stock icons. - How do we choose which icons should be included in the stock? *Icon Sizes* - Default image size of 16x16 - Should sizes be predefined identifiers, e.g. tiny, small, medium, large? - What sizes are acceptable? - Platform differences - Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and 512×512 pixels and multiple states - Windows XP supports: 16x16, 32x32, 48x48 and upscales up to 256x256 - Should an arbitrary integer be allowed causing a potential scaling of icons? *Naming of URI* - Should we use about:icon or res:icon rather than add a new scheme? - IMO, icon: is still the ideal choice. The two big ones are: the allowance of the file:// syntax versus adding a getIconURI() type method to the FileUpload object and the support for stock images. Perhaps the file:// syntax can work for internal and local pages in the same way that the file URI only works locally. Whereas the FileUpload object can be used to retrieve the icon URI or data URI or something. I'm guessing the icon URI returned would have to be using the icon:file-extension syntax? For the stock images, if people could comment on the plausibility of this option. 2010/2/1 Ian Fette (イアンフェッティ) ife...@google.com Just to be clear, I believe Pierre was referring to file extensions (e.g. .jpg) not browser extensions. At any rate, I think it would be convenient, if you are able to get a File handle, to also be able to get an image representation of the file. That could be some thumbnail if the OS has already generated and stored a thumbnail and it's essentially free to get it on the platform, or if a thumbnail is not available (or perhaps regardless of whether or not a thumbnail is available) you could get some other image representation that is somehow representative of the file type (e.g. some icon for JPEG files -- this image does not need to be part of the standard, does not need to be consistent across browsers, but should ideally be consistent for all JPEG files you call geticon on within the same UA on the same computer... My
Re: [xhr] events for async requests
On Mon, 01 Feb 2010 13:26:46 +0100, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 1, 2010 at 4:12 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking jo...@sicking.cc wrote: Where in the spec is this defined? I guess my answer is yes, it'd be nice if it was more explicit. :) You haven't even read the specification on this yet? :/ See step 9 under the send() method: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ In particular the two sections flagged with If the asynchronous flag is true. I have read the spec, but I still don't see where it says that responseText and the state is updated from the same task. responseText is just an attribute. The specification specifically says to update the response entity body. This makes more sense as well given that we will introduce some kind of attribute returning a ByteArray in the future. Is the idea that every bullet under The same-origin request event rules are as follows is always performed from the same task? Yes. But even then the actual updating of the state is not listed in the same set of bullets. That does not mean they are a separate task (if that were so it would be said). It just means their definition lies somewhere else (to avoid duplication). -- Anne van Kesteren http://annevankesteren.nl/
Re: Steps to creating a browser standard for the moz-icon:// scheme
On Feb 1, 2010, at 4:04 AM, Pierre-Antoine LaFayette wrote: Yes but in Windows XP they upscale anything over 48x48 I believe. According to the internets, icons for Windows Vista or later are supposed to include bitmaps up to 256x256 (6 total sizes in the standard format) and will actually be used. Previous versions of Windows only used sizes up to 64x64. Icons for Mac OS X Leopard or later are supposed to include bitmaps up to 512x512 (also 6 total sizes). Previous versions only went up to 128x128. In all cases, the OS will interpolate other sizes. http://en.wikipedia.org/wiki/Apple_Icon_Image_format http://en.wikipedia.org/wiki/ICO_(icon_image_file_format) By contrast, iPhone OS app icons are 57x57. Regards, Maciej On 1 February 2010 01:24, timeless timel...@gmail.com wrote: 2010/1/29 Pierre-Antoine LaFayette pierre.lafaye...@gmail.com: Perhaps if we found some creative commons icons to use as defaults for the most used extensions. It wouldn't match the native theme but at least we'd have something for cases where platform icons are not available. We'd need to have some number of sizes. I think Windows goes to a max of 72x72, while Mac OSX goes to 128x128. Mozilla defines the size as: No. Windows does 256x and OS X does 512x. At least, I've shipped such icons on behalf of Nokia and they seemed to match what Windows 7 and OS X wanted. http://www.macworld.com/article/60877/2007/11/big105icons.html http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm -- Pierre.
Re: XHR LC comment: header encoding
Anne van Kesteren wrote: On Tue, 05 Jan 2010 13:49:55 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Apart from the obvious worry of switching away from a behavior that the vast majority of UAs currently implement, with the ensuing potential for website breakage, sounds fine... I know... Though Opera not having received bug reports so far on this issue gives me some hope, since we have received lots of other bug reports on far more minor details starting very early on. The editor drafts of XHR1 and XHR2 now include the change. This also moved things away from being defined in Unicode to a combination of bytes and ASCII. Please let me know if you (i.e. anyone reading this thread) have any editorial suggestions on my changes or if I missed something while making the edits. Specifically search for inflate and deflate throughout the drafts: http://dev.w3.org/2006/webapi/XMLHttpRequest/ http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ ... I've got a question. You know have several parts where you say something like: If any code point in method is higher than U+00FF LATIN SMALL LETTER Y WITH DIAERESIS or after deflating method it does not match the Method token production raise a SYNTAX_ERR exception and terminate these steps. a) the part about U+00FF seems to be redundant with the requirement for deflate not to loose information, and b) as Method token (actually token in HTTP/1.1) does not allow non-ASCII characters anyway, it appears to be much simpler to just require conformance to that ABNF. So this is probably correct, but appears to be way too verbose to me... Best regards, Julian
Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Mon, Feb 1, 2010 at 10:47, Ian Hickson i...@hixie.ch wrote: On Sun, 31 Jan 2010, Sebastian Andersson wrote: On Sat, Jan 30, 2010 at 10:31, Ian Hickson i...@hixie.ch wrote: Right now, today, if I were to expose a WebSocket service on my Dreamhost shared server, I could do so without any trouble. If we used a scheme such as the one described above using a policy file, anyone else also hosting their site on the same server could grant access to my server to their scripts on their page. Whether this is a technical or administrative issue, it's an issue we have to handle today. If you only allow the policy file from being read from a single port How would we do that? I think it is pretty obvious. Do it like Silverlight! The policy file is downloaded from port 943. If it is not available there, you have no right to connect to this IP number. How do you protect your Web Socket service from another user on your shared host? They can publish flash clients and java applets that connects to your server and present any origin they want. IMHO, yes. I understand that security is a tradeoff between risk and reward, but fundamentally, it seems to me that it is far off the risk/reward scale to design a system in such a way that a security problem cannot be fixed when it is discovered. Having the user agent cache the security policy and act on that cached version even after a security problem has been found prevents security problems from being fixed in a timely manner. Sure, it would cause a downtime We should not design our protocol in such a way that a configuration mistake in a security policy can only be fixed by forcing downtime on existing users. But a mistake in the policy file is not enough. The administrator must make a mistake when writing the policy file, there must be some malicious code together with users that run the code together with a service that has a vulnerability running on the same server to get a problem. If all these things are combined, then you may need some downtime to fix it (and while you are at it, patch/reconfigure the service that was vulnerable to protect against native malware of the same kind). With a configurable timeout value in the policy file (which is lacking in flash's policy files, yet they are cached for some time), then the administrator could even decide what is right for their site. I think you worry too much about a problem that most administrators already have to face when deploying java, flash or silverlight solutions, so they should already be aware of it. With the Web Socket protocol: - Existing services would have to be changed if they should be accessible (with the risk of bugs, duplication of existing access control and logging). This is intentional, to prevent pages from abusing existing services. Yes, it was intentional, but it is still a drawback. For me it prevents all the cases where I would want to use the API today (replacing existing flash solutions without having to make changes on the server side). - Requires all new services to implement the policy mechanism correctly. It's pretty trivial to implement. Yes, but it still has to be implemented correctly in every server. -- Instead of just having a few correct implementations in the clients (that already have code for origin handling and whose designers hopefully are aware of the problems), each server will have to have it with associated risks of errors. A huge potential for new security problems. Will of course be cheaper and less risky when libraries are available for most languages, but still many more implementations. I don't understand. Why would the servers have it? It's the client that enforces the security policy. From section 5.1 in the protocol specification: Servers that are not intended to process input from any Web page but only for certain sites should verify the Origin header is an origin they expect, and should only respond with the corresponding WebSocket-Origin if it is an accepted origin I think that covers a large proportion of the servers and I think that most projects would want to implement support for it just to allow different server deployment scenarios. - Native clients against a new service would have to use the Web Socket protocol too. If it's a Web Socket subprotocol... then yes. I wouldn't recommend that people use this protocol for designing protocols intended to be used by native clients other than browsers, though obviously that's possible too. -- Adds a little extra cost and risks. Will of course be cheaper and less risky when libraries are available for most languages, but still way more implementations. Than what? I'm confused. Web Socket is really trivial to implement -- the whole point is to make it easy to implement so anyone can do it. It's like CGI, intended for anyone to be able to hack something up quickly. Compared to straight TCP it is more code. You must also read
Re: File API: Blob and underlying file changes.
Going a bit back to current spec and changing underlying files - here is an update on our thinking (and current implementation plan). We played with File/Blob ideas a little more and talked with some of our app developers. In regard to a problem of changing file, most folks feel the Blob is best to be though of as a 'snapshot of a byte range' with a delayed promise to deliver the actual bytes in that range from the underlying data storage. It is a 'delayed promise' because all the actual 'reading' methods are async. Basically, in terms of implementation, the Blob is not a 'container of bytes' but rather a 'reference' to the byte range. As such, the async read operations later may fail, for many reasons - the file can be deleted, renamed, modified, etc. It seems developers sometimes want to be oblivious to those problems, but in other scenarios they want to process them. Basically, it's app-specific choice. It appears that the following implementation goes along with the current edition of the spec but also provides the ability to detect the file change: 1. File derives from Blob, so there is a File.size that performs synchronous file I/O. Not ideal, but easy to use and compatible with current forms upload. 2. File.slice() also does a synchronous IO and captures the current size and modification time of the underlying file - and caches it in the resulting Blob. 3. Subsequent Blob.slice() and Blob.size calls do not do any file IO, but merely operate on cached values. So the only Blob methods that do sync IO are those on the File object. Subsequent slicing operates on the file information captured from File and propagate it to derived Blobs. 4. In xhr.send() and FileReader, if the UA discovers that the underlying file is changed, it behaves just like when other file errors are discovered - returning 'error' progress event and setting FileReader.error attribute for example. We might need another FileError code for that if existing ones do not feel adequate. This way, the folks who don't care about changing files could simply ignore the error results - because they likely do not worry about other errors as well (such as NOT_FOUND_ERR). At the same time, folks that worry about such things, could simply process the errors already specified. It also doesn't add new exceptions to the picture so no special code is needed in simple cases. One obvious difficulty here is the synchronous file IO on File.size and File.slice(). Trying to eliminate it requires some complexity in API that is not obviously better. It either leads to some strange APIs like a getSize() with a callback that delivers the size, or/and breaks behavior of currently implemented File (and most developer's expectations). In any case, an attempt to completely avoid sync IO and preserve correctness seems to be calling for a way more involved API. Considering that most uploaders which slice the file and send it in pieces will likely do it in a worker thread, sync IO in these places perhaps is a lesser evil then complicated (or dual) API... Thanks, Dmitry On Wed, Jan 27, 2010 at 4:40 AM, Juan Lanus juan.la...@gmail.com wrote: On Wed, Jan 27, 2010 at 01:16, Robert O'Callahan rob...@ocallahan.org wrote: 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 Right, not talking about locks any more because it would be telling HOW the UA should do it, and what is best for the UA developers is to be told WHAT to do. Not writing a tutorial but a specification. Let the developer find out how to do it, this year, and with the tools that will be available by 2020. Now, out of the locks subject, what I want to be sure of is that the specification does not specify the mutating blob, the origin of this thread. -- Juan He was pierced for our transgressions, he was crushed
Re: File API: Blob and underlying file changes.
On Mon, Feb 1, 2010 at 12:27 PM, Dmitry Titov dim...@chromium.org wrote: Basically, it's app-specific choice. It appears that the following implementation goes along with the current edition of the spec but also provides the ability to detect the file change: 1. File derives from Blob, so there is a File.size that performs synchronous file I/O. Not ideal, but easy to use and compatible with current forms upload. 2. File.slice() also does a synchronous IO and captures the current size and modification time of the underlying file - and caches it in the resulting Blob. Note that the synch IO is not required by the spec. You can just cache the filesize when the File object is created, which always happens asynchronously. Then used that cached value through all calls to File.size and Blob.slice(). 4. In xhr.send() and FileReader, if the UA discovers that the underlying file is changed, it behaves just like when other file errors are discovered - returning 'error' progress event and setting FileReader.error attribute for example. We might need another FileError code for that if existing ones do not feel adequate. This is definitely an interesting idea, possibly even something that we should standardize. I don't really feel strongly either way, though I am curious about platform support if the file lives in NFS or samba or some such. One obvious difficulty here is the synchronous file IO on File.size and File.slice(). Trying to eliminate it requires some complexity in API that is not obviously better. See above. / Jonas
[WebSQLDatabase] Minor change to spec?
In section 4.3.2, point 6, the In case of error... paragraph says: 2. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. I'm proposing the following change (the wording could be different, of course): 2. If the error callback returns false *and the transaction is not in an unrecoverable state*, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, if the error callback did not return false, or there was no error callback, *or the transaction is an unrecoverable state*, jump to the last step in the overall steps. This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: If certain kinds of errors occur on a statement within a multi-statement transaction (errors including SQLITE_FULLhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_IOERR http://www.sqlite.org/c3ref/c_abort.html, SQLITE_NOMEMhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_BUSY http://www.sqlite.org/c3ref/c_abort.html, and SQLITE_INTERRUPThttp://www.sqlite.org/c3ref/c_abort.html) then the transaction might be rolled back automatically. If such an error occurs, we cannot move on to the next statement as currently requested by the spec. Thanks, Dumi
Re: [WebSQLDatabase] Minor change to spec?
On Mon, 1 Feb 2010, Dumitru Daniliuc wrote: In section 4.3.2, point 6, the In case of error... paragraph says: 2. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. I'm proposing the following change (the wording could be different, of course): 2. If the error callback returns false *and the transaction is not in an unrecoverable state*, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, if the error callback did not return false, or there was no error callback, *or the transaction is an unrecoverable state*, jump to the last step in the overall steps. This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: If certain kinds of errors occur on a statement within a multi-statement transaction (errors including SQLITE_FULLhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_IOERR http://www.sqlite.org/c3ref/c_abort.html, SQLITE_NOMEMhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_BUSY http://www.sqlite.org/c3ref/c_abort.html, and SQLITE_INTERRUPThttp://www.sqlite.org/c3ref/c_abort.html) then the transaction might be rolled back automatically. If such an error occurs, we cannot move on to the next statement as currently requested by the spec. These fall under the general User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. rule, under which you can basically do whatever you need to do to handle unexpected errors. If I edit the spec again, I'll make this more clear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebSQLDatabase] Minor change to spec?
Thanks for clarifying this, Ian. Dumi On Mon, Feb 1, 2010 at 4:53 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 1 Feb 2010, Dumitru Daniliuc wrote: In section 4.3.2, point 6, the In case of error... paragraph says: 2. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. I'm proposing the following change (the wording could be different, of course): 2. If the error callback returns false *and the transaction is not in an unrecoverable state*, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, if the error callback did not return false, or there was no error callback, *or the transaction is an unrecoverable state*, jump to the last step in the overall steps. This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: If certain kinds of errors occur on a statement within a multi-statement transaction (errors including SQLITE_FULLhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_IOERR http://www.sqlite.org/c3ref/c_abort.html, SQLITE_NOMEMhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_BUSY http://www.sqlite.org/c3ref/c_abort.html, and SQLITE_INTERRUPThttp://www.sqlite.org/c3ref/c_abort.html) then the transaction might be rolled back automatically. If such an error occurs, we cannot move on to the next statement as currently requested by the spec. These fall under the general User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. rule, under which you can basically do whatever you need to do to handle unexpected errors. If I edit the spec again, I'll make this more clear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.
On Mon, 1 Feb 2010, Sebastian Andersson wrote: On Mon, Feb 1, 2010 at 10:47, Ian Hickson i...@hixie.ch wrote: On Sun, 31 Jan 2010, Sebastian Andersson wrote: On Sat, Jan 30, 2010 at 10:31, Ian Hickson i...@hixie.ch wrote: Right now, today, if I were to expose a WebSocket service on my Dreamhost shared server, I could do so without any trouble. If we used a scheme such as the one described above using a policy file, anyone else also hosting their site on the same server could grant access to my server to their scripts on their page. Whether this is a technical or administrative issue, it's an issue we have to handle today. If you only allow the policy file from being read from a single port How would we do that? I think it is pretty obvious. Do it like Silverlight! The policy file is downloaded from port 943. If it is not available there, you have no right to connect to this IP number. So anyone who's behind a firewall that blocks all but ports 80 and 443 is blocked from using Web Sockets? That's a pretty serious problem. How do you protect your Web Socket service from another user on your shared host? They can publish flash clients and java applets that connects to your server and present any origin they want. Like I said, Flash has all kinds of security problems. (The risk in this case is minimal, though, since it wouldn't send ambient authority headers -- like Cookies -- with the request, which are the main problem in a shared hosting environment.) -- Instead of just having a few correct implementations in the clients (that already have code for origin handling and whose designers hopefully are aware of the problems), each server will have to have it with associated risks of errors. A huge potential for new security problems. Will of course be cheaper and less risky when libraries are available for most languages, but still many more implementations. I don't understand. Why would the servers have it? It's the client that enforces the security policy. From section 5.1 in the protocol specification: Servers that are not intended to process input from any Web page but only for certain sites should verify the Origin header is an origin they expect, and should only respond with the corresponding WebSocket-Origin if it is an accepted origin I think that covers a large proportion of the servers and I think that most projects would want to implement support for it just to allow different server deployment scenarios. I would imagine most would only accept connections from _one_ site, and they can just send back the appropriate WebSocket-Origin without checking what the client has sent. Fundamentally, raw sockets plus a policy file is a completely different approach than Web Sockets. I would recommend developing a second proposal separate from the Web Sockets spec, and approaching browser vendors to see if they prefer it. Ok. Perhaps I'm pessimistic here, but I fear that one important browser vendor would prefer that raw sockets were not added so their own competing technology remains a better choice and if the Web Socket protocol is part of html 5, it is easier for them to just say no. I hope I'm wrong though. Well if that's the case, we wouldn't be able to change Web Socket either. For the rest of your points, we're basically just disagreeing with each other's priorities, not with the facts. So I don't think we can make much progress. Your ideas are not wrong, they're just solving a different set of problems, or a set of problems with different priorities, than what Web Socket is setting out to solve. I really _would_ recommend approaching browser vendors and seeing if they would prefer a different approach, or another approach in addition to this one, and then if they do, editing a spec for that new approach. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
A few comments inline marked with [PC]. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Nikunj Mehta Sent: Sunday, January 31, 2010 11:37 PM To: Kris Zyp Cc: Arthur Barstow; public-webapps Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On Jan 27, 2010, at 1:46 PM, Kris Zyp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a count property that returns the total number of objects that share the current key. There is still no way to determine how many objects are within a range. Was the intent to make count return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). I agree with the concept. I have doubts about implementation success. However, I will include this in the editor's draft. [PC] I agree with Nikunj, I suspect that a implementations will have to just compute the count, as it's unlikely that updating intermediate nodes in the tree for each update would be desired (to try to maintain extra information for fast range size computation). At that point it's almost the same as user code iterating over the range (modulo the Javascript interface overhead). I'm also not sure how often you'd use this, as it would only work on simple conditions (no composite expressions, no functions in expressions) that happen to have an index. * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. Thanks for the pointer. I will look in to this as even Pablo had related requirements. [1] http://wiki.commonjs.org/wiki/Promises and a comment on this: On 1/26/2010 1:47 PM, Pablo Castro wrote: 11. API Names a. transaction is really non-intuitive (particularly given the existence of currentTransaction in the same class). beginTransaction would capture semantics more accurately. b. ObjectStoreSync.delete: delete is a Javascript keyword, can we use remove instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving delete. I certainly prefer delete in preserving the familiarity of REST terminology. [PC] I understand the term familiarity aspect, but this seems to be something that would just cause trouble. From a quick check with the browsers I had at hand, both IE8 and Safari 4 reject scripts where you try to add a method called delete to an object's prototype. Natively-implemented objects may be able to work-around this but I see no reason to push it. remove() is probably equally intuitive. Note that the method continue on async cursors are likely to have the same issue as continue is also a Javascript keyword. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3 X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU =W6Jx -END PGP SIGNATURE- -pablo
