Seeking agenda items for WebApps' Nov 1-2 f2f meeting
The WebApps WG will meet face-to-face November 1-2 as part of the W3C's 2010 TPAC meeting week [TPAC]. I created a stub agenda item page and seek input to flesh out agenda: http://www.w3.org/2008/webapps/wiki/TPAC2010 [TPAC] includes a link to the Registration page, a detailed schedule of the group meetings, and other useful information. The registration fee is 40€ per day and will increase to 120€ per day after October 22. -Art Barstow [TPAC] http://www.w3.org/2010/11/TPAC/
Re: [IndexedDB] Constants and interfaces
On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org wrote: Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I believe we had decided that all the objects with constants would have an interface object hanging off of window so it's possible to simply say IDBKeyRange.LEFT_BOUND within JavaScript. What happens when someone tries something like the following JS: |IDBCursor.continue()|? Given that we're using an interface object, I'd assume we throw some sort of exception or something? I tried to figure out the answer in the WebIDL spec (I imagine it's somewhere around here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object ) but it's a lot to wade through. Any advice would be great. I definitely think we should handle this the same way that all other interfaces does it. I.e. the same way that window.Node.appendChild(...) does it. In the Firefox implementation we just fall back to using our generic code for all this stuff, so nothing special goes on in the IndexedDB implementation. And yes, I think WebIDL should be the one defining what should happen. If it doesn't already someone should file a bug :) Ok, I figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in I think I'd only support this if it was just a stop-gap measure until WebIDL could add proper support. Is there any way to bring this up with those folks and get their feelings on the subject so whatever we do is consistent with the future directions of that spec? javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? It's possible, sure, but is anything like
Re: Lifetime of Blob URL
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren ann...@opera.comwrote:
On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher da...@chromium.org
wrote:
Another idea (possibly a crazy one) would be to eliminate Blob, and just
use File for everything. We could rename BlobBuilder to FileBuilder and
have it return a File instead of a Blob. Same goes for Blob.slice(). Of
course,
the File would not necessarily correspond to a real physical file on disk
for performance reasons.
Not having Blob at all works for me!
I gave this some more thought. Here's some issues I came up with:
1) BlobBuilder - FileBuilder
This renaming seems to suggest the creation of a file, which is not the
intent at all.
2) XHR.{asBlob,responseBlob} - XHR.{asFile,responseFile}
This renaming seems to suggest the creation of a file, which is not
necessary for small responses.
3) Combine Blob and File into a single File interface
This merging has the unfortunate side-effect of introducing a name
property for the result of a
File.slice() operation. It also means that the result of FileBuilder and
XHR.responseFile would
have a name.
Considering the above, it seems like there is a place for Blob (or something
like it).
I can see Jonas' points about BlobReader vs. FileReader, and so I'm happy to
backpedal and go with
FileReader, FileException, and FileError, keeping Blob for cases where we
don't promise a file.
-Darin
Blob/File naming
On Monday, August 30, 2010 1:09 PM, Jonas Sicking wrote: On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com wrote: *sigh. Naming continues to be hard. Not everyone's thrilled with the proliferation of Blob in the API [1] including other major implementors (my co-editor included ;-)) but I changed it mainly due to Darin/Jian/other objections. I suppose you folks are pretty adamant on the Blob* name? I feel pretty strongly that we should name this back to FileReader, for several reasons: 1. Most people that I talk to dislike the name Blob, much less having it spread to things like BlobReader. 2. My understanding is that the writer counterpart is going to be called FileWriter (is this correct?) 3. While it's certainly possible to read Blobs with this, it seems to me like the far most common case will be to read a real file, or part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader It's easy to bike shed on naming and I don't really want to get into that. I'd prefer we just settled on something and stick to it. However I will offer some observations from the conversations we've been having on this topic. I like the abstraction of Blob away from File with File being a concrete implementation of the Blob interface. I suspect going back to just File adds a bunch of unnecessary things to the cases where the data isn't file backed. It seems there are a proliferation of specs that reference the Blob concept. In fact the confusion in my conversations with people over the name has been about a Blob here being more like a Stream than what they traditionally think of as a BLOB (with a url property for example). We think using Blobs with XHR and IndexedDB, say, will become at least as common as their use for reading files from the file system. Cheers, Adrian.
Re: [XHR] Redirects
On Fri, Aug 27, 2010 at 5:50 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 31, 2010 at 4:41 AM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org wrote: Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I believe we had decided that all the objects with constants would have an interface object hanging off of window so it's possible to simply say IDBKeyRange.LEFT_BOUND within JavaScript. What happens when someone tries something like the following JS: |IDBCursor.continue()|? Given that we're using an interface object, I'd assume we throw some sort of exception or something? I tried to figure out the answer in the WebIDL spec (I imagine it's somewhere around here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a lot to wade through. Any advice would be great. I definitely think we should handle this the same way that all other interfaces does it. I.e. the same way that window.Node.appendChild(...) does it. In the Firefox implementation we just fall back to using our generic code for all this stuff, so nothing special goes on in the IndexedDB implementation. And yes, I think WebIDL should be the one defining what should happen. If it doesn't already someone should file a bug :) Ok, I figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in I think I'd only support this if it was just a stop-gap measure until WebIDL could add proper support. Is there any way to bring this up with those folks and get their feelings on the subject so whatever we do is consistent with the future directions of that spec? I can't say that I care much. Adding it to WebIDL seems fine, though I also could see the argument that if no other classes than IDBKeyRange needs multiple constructors, then there isn't much value to adding it to WebIDL. But I'm all for proposing it for inclusion in WebIDL. javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other
Re: [XHR] Redirects
On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher da...@chromium.org wrote: So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? Yeah, or you could reset the existing object using open(). One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Yeah, though I think that the people that implement redirects manually have put some thought in the matter. Maybe that is naive, though on the other hand if people do it wrong it does not matter much either. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... If this is actually common and people start using this a lot and ask this question here that would be the point where we should start thinking about making this less awkward. For now libraries and developers with lots of time have all the hooks they need. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Tue, Aug 31, 2010 at 1:16 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher da...@chromium.org wrote: So the idea is that you would have to manually create the redirect request using a new XHR if you wanted to manually follow the redirect? Yeah, or you could reset the existing object using open(). One risk with that is that it is easy to construct the redirect request improperly. There's the classic example of what happens when you issue a POST request and it results in a redirect. 303 and 307 had to be invented because some browsers implemented 302 incorrectly. Yeah, though I think that the people that implement redirects manually have put some thought in the matter. Maybe that is naive, though on the other hand if people do it wrong it does not matter much either. Maybe there should be a way to create a new XHR from the existing XHR that is already configured to follow the redirect? I'm not sure how to make this less awkward... If this is actually common and people start using this a lot and ask this question here that would be the point where we should start thinking about making this less awkward. For now libraries and developers with lots of time have all the hooks they need. Hmm, that's a pretty good argument. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. The classical example is a server that redirects back to the same URL with a Set-Cookie header, expecting the next request to have a corresponding Cookie header. If the Cookie header is not added, then the redirect is issued again. Most browsers detect this after N iterations, and then give up. Of course, this situation only occurs if the user has disabled cookies in the User Agent. I worry that a case like this will almost never be tested by application developers, and hence, users who like to disable some cookies will be unable to use the internet. (I realize that the internet is mostly broken already if you disable cookies, but there are some variations of cookie blocking that sort of work.) A User Agent could try to implement a heuristic to catch certain flavors of redirect chains, by observing the XHR requests made by an application. But, it seems like it would be fairly difficult to avoid false positives. If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Otherwise, the redirect would be processed normally. The result being that application authors would be guided away from following redirects manually, and hence they would avoid the problems I've described above. -Darin
Re: [IndexedDB] Constants and interfaces
On 8/31/2010 12:03 PM, Jonas Sicking wrote: So IMHO we should heavily optimize for javascript, while ensuring that other languages are possible. Yes, please. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [XHR] Redirects
On , Anne van Kesteren ann...@opera.com wrote: On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Thank you. But there is one thing missing: the final url in case of a redirect chain. Currently that is not possible to guess for non xml requests or HEAD requests. My use case was about doing a HEAD and reading the Location header to know if was going to be redirected. Now I could set followRedirects to false and read it, but for cases where the redirection chain is followed, then new url is not available. Something like finalUrl which when readyState is = 1 it would have the value passed to open() and after, when the value is = 2 (headers received) it would have the value of the final url. Another issue that concerns me is redirect loops. The proposed API gives us know way to know that the application is following a redirect chain, which means that we have little way to know if the application is following an endless redirect chain. Following redirects is the default behavior, and user agents abort after N iterations regardless of whether it's XHR or a regular request. The new followRedirects feature is for opting into disabling it. If instead, we had an API for auditing redirects (perhaps an onredirect event), then we could let developers handle that event and call preventDefault if they want to stop redirect processing. Quite an edge case, but setting followRedirects to false and then creating individual XHRs for each 302 response explicitly should work.
