Re: [File API] Recent Updates To Specification + Co-Editor
+1 to window.createBlobUrl(blob) and window.revokeBlobUrl(url) , they make lifetime of a blob url (which is different from lifetime of the Blob JS object) way more clear to me, since it attaches it explicitly to a window, and to a specific window in that. Multi-window web apps (like GMail or IM) have multiple windows that cross-script each other, so it's very easy to change the code a little and the 'spawning Document, as defined in the spec now, changes, since it's implicitly captured. Explicit is good. It also indeed makes it possible for a good-behaving app to prevent a memory leak in long-lived pages and potentially shared workers, since it gives an explicit 'revoke' method. Nice idea, lets see if it can be added to the spec. Dmitry On Wed, Jun 30, 2010 at 5:38 PM, Jian Li jia...@chromium.org wrote: Thanks for the update. We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.comwrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed
Re: [File API] Recent Updates To Specification + Co-Editor
On Thu, Jul 1, 2010 at 11:47 AM, Dmitry Titov dim...@chromium.org wrote: +1 to window.createBlobUrl(blob) and window.revokeBlobUrl(url) +1 too, presumably these would also be available workers, particularly shared workers. , they make lifetime of a blob url (which is different from lifetime of the Blob JS object) way more clear to me, since it attaches it explicitly to a window, and to a specific window in that. Multi-window web apps (like GMail or IM) have multiple windows that cross-script each other, so it's very easy to change the code a little and the 'spawning Document, as defined in the spec now, changes, since it's implicitly captured. Explicit is good. By factoring the .url property out, the Blob object itself acts much more like a String primitive in that it's an immutable container for data that can be passed freely throughout a graph of connected browsing contexts, and potentially serialized and sent via PostMessage. Overall simpler to grok w/o the 'spawning context' concept. It also indeed makes it possible for a good-behaving app to prevent a memory leak in long-lived pages and potentially shared workers, since it gives an explicit 'revoke' method. Nice idea, lets see if it can be added to the spec. Dmitry On Wed, Jun 30, 2010 at 5:38 PM, Jian Li jia...@chromium.org wrote: Thanks for the update. We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.comwrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an
Re: [File API] Recent Updates To Specification + Co-Editor
One more question. Should we also rename FileError to BlobError and FileException to BlobException in order to be consistent with the naming changes? Thanks, Jian On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of the File API specification. Most people who work on HTML5 and WebApps know Jonas' contributions to both WGs; with everyone's consent, I'd like to nominate him as co-editor. His model for an asynchronous event-driven API is what prompted the initial rewrite, and he also works on both File API and IndexedDB implementation (amongst other things). -- A* [1] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: [File API] Recent Updates To Specification + Co-Editor
We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of the File API specification. Most people who work on HTML5 and WebApps know Jonas' contributions to both WGs; with everyone's consent, I'd like to nominate him as co-editor. His model for an asynchronous event-driven API is what prompted the initial rewrite, and he also works on both File API and IndexedDB implementation (amongst other things). -- A* [1] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: [File API] Recent Updates To Specification + Co-Editor
Thanks for the update. We've some more questions regarding the blob URL. 1. The spec does not describe how blob and blob URL will work in the worker and shared worker scenarios. I think we should allow WorkerGlobalScope to be the binding context for the blob URL, like Document. In addition, we should define how a blob object can be passed to the worker via structured cloning. A new blob object should be expected to be created and it points to the same underlying data. 2. The current spec says that the lifetime of the blob URL is bound to the lifetime of the spawning context. What happens if we try to access the blob url from multiple contexts? Say, we call parent.blob.url, the lifetime of the url is bound to the parent context, not the current context, per the spec. This sounds a little bit unnatural. Could we explicitly provide the context while creating the blob URL, like window.createBlobUrl(blob)? 3. Since the lifetime of the blob URL is bound to a context, the blob URL (the underlying blob data) will get disposed only when the context dies. When we have long-live pages or shared workers, we could have leaked blob URLs that result in unclaimed blob storages. It will be nice if we can add the capability to revoke the blob URL pragmatically, like window.revokeBlobUrl(url), 4. It will be good if the spec could say more about the lifetime of the blob object and the blob URL since they're kind of orthogonal: the blob object will still be functional as long as it is not GC-ed even if the associated context dies. 5. The spec does not describe explicitly about the transient cases, like location.href = blob.url. Probably the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of the File API specification. Most people who work on HTML5 and WebApps know Jonas' contributions to both WGs; with everyone's consent, I'd like to nominate him as co-editor. His model for an asynchronous event-driven API is what prompted the initial rewrite, and he also works on both File API and IndexedDB implementation (amongst other things). -- A* [1] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: [File API] Recent Updates To Specification + Co-Editor
Hi Arun, On 28.06.2010 23:20, Arun Ranganathan wrote: ... 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. That being said, nits below: - it's a URI scheme, not a URL scheme - you want to use RFC 5234, not 2234 for ABNF (that just changes the reference) - MAY use UUIDs doesn't make sense if it's really opaque. I'll assume that opaqueString will allow all characters used in UUIDs, so you really don't need a BCP 14 keyword here. Just state that it might be a good choice. - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) I recommend to do another round of edits on this, and then include the URI review mailing list into further discussions. Best regards, Julian
Re: [File API] Recent Updates To Specification + Co-Editor
On 6/29/10 11:09 AM, Julian Reschke wrote: Hi Arun, On 28.06.2010 23:20, Arun Ranganathan wrote: ... 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. Both you and I may sound like broken records, since we've definitely been down this road before :) I do plan to register it via IANA. Note that we started off with a URN scheme (urn:uuid). This was chosen initially to bypass a cycle with IANA, but this wasn't adequate. No browser implementation really uses URN schemes; they aren't used in web pages; implementers, including Firefox, cited a preference for URLs with a scheme (for instance, nightly builds of Firefox use moz-filedata: as a scheme). Moreover, we wanted something that could be used in all places on the web platform that URLs are used today, including Web APIs like XMLHttpRequest, and for elements (like img src..). Lastly, while a URN scheme could have been used with an attribute called URL, that seemed wrong. We have file URIs (file://) on the web platform today, and some implementations actually support use such as that mentioned above. But a scheme that referred to individual Blobs or Files that could be used with response codes was the best course of action (with no path, etc.). That being said, nits below: - it's a URI scheme, not a URL scheme Duly noted; this is a mistake on my part. - you want to use RFC 5234, not 2234 for ABNF (that just changes the reference) Duly noted; I'll fix this. - MAY use UUIDs doesn't make sense if it's really opaque. I'll assume that opaqueString will allow all characters used in UUIDs, so you really don't need a BCP 14 keyword here. Just state that it might be a good choice. Hmm... fair enough. - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? It is likely to be unique per producer. In fact, Chrome folks may wish to use origin tokens in the URI scheme, and even if they didn't, the use of UUID would result in differences per producer. If by different producers, you mean that a Blob URI coined by Chrome may have no meaning in Firefox, you're likely to be right. While the *format* that the URI takes may vary per producer, it seems wise to at least define a scheme that can be used commonly by user agents. Authors may never interact with the URI itself, but only with the Blob.url property -- that is true. But at least a scheme gets us something that's better than total arbitrariness. Do you disagree strongly? I also think that leaving things undefined isn't desirable in general. - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself That's right. I want to emphasize that they are allowed. I took this from the RFC on WWW URIs, cited in the text. Maybe I can add a non-normative section on the use of fragment identifiers? Is that your suggestion? - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) Right -- I do in the spec. They depend entirely on the media type of a Blob. Is the existing text insufficient? I recommend to do another round of edits on this, and then include the URI review mailing list into further discussions. Good suggestion, thanks Julian. -- A*
Re: [File API] Recent Updates To Specification + Co-Editor
On 29.06.2010 20:40, Arun Ranganathan wrote: ... I may sound like a broken record, but it's still not clear to me why you need a custom URI scheme here. If you plan to actually register it with IANA (you do, right?), you will have to explain why it's needed. Both you and I may sound like broken records, since we've definitely been down this road before :) I know :-) I do plan to register it via IANA. Note that we started off with a URN scheme (urn:uuid). This was chosen initially to bypass a cycle with IANA, but this wasn't adequate. No browser implementation really uses URN schemes; they aren't used in web pages; implementers, including Firefox, cited a preference for URLs with A URN is a URI. blob is a would-be URI as well. No web page uses blob right now, so I'm not sure what point you're trying to make. a scheme (for instance, nightly builds of Firefox use moz-filedata: as a scheme). Moreover, we wanted something that could be used in all places on the web platform that URLs are used today, including Web APIs like XMLHttpRequest, and for elements (like img src..). Lastly, while a URN scheme could have been used with an attribute called URL, that seemed wrong. I don't see why you can't do these things with urn:uuid:. We have file URIs (file://) on the web platform today, and some implementations actually support use such as that mentioned above. But a scheme that referred to individual Blobs or Files that could be used with response codes was the best course of action (with no path, etc.). All true understood; but I still don't see why this needs a new URI scheme. ... - How do you guarantee uniqueness if opaqueString is free form? Is this just unique per producer? Are you sure that never ever two blob URIs from different producers will get into the same context? If you're sure about that, why do you need a URI scheme in the first place? It is likely to be unique per producer. In fact, Chrome folks may wish to use origin tokens in the URI scheme, and even if they didn't, the use of UUID would result in differences per producer. If by different producers, you mean that a Blob URI coined by Chrome may have no meaning in Firefox, you're likely to be right. So if a blob URI produced by Firefox leaks into Chrome, what happens? If this *can* happen, you may need to require more than per-producer uniqueness. While the *format* that the URI takes may vary per producer, it seems wise to at least define a scheme that can be used commonly by user agents. Authors may never interact with the URI itself, but only with the Blob.url property -- that is true. But at least a scheme gets us something that's better than total arbitrariness. Do you disagree strongly? I also think that leaving things undefined isn't desirable in general. I actually do not see what benefit this scheme brings. - You don't need to make statements about fragment identifiers; they are not part of the URI scheme itself That's right. I want to emphasize that they are allowed. I took this from the RFC on WWW URIs, cited in the text. Maybe I can add a non-normative section on the use of fragment identifiers? Is that your suggestion? The semantics of fragment identifiers follow from RFC 3986, Section 3.5 (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5) and the media type that is being retrieved. So normative statements would be incorrect, but explaining what's going on wouldn't hurt. - That being said, if you do you should point out how they work (do they depend on the media type of a representation?) Right -- I do in the spec. They depend entirely on the media type of a Blob. Is the existing text insufficient? I didn't see it. Most is accurate. I'd rephrase This scheme can allow for fragment identifiers for well-defined format types though. The scheme can't allow or disallow anything; it really only depends on the media types of the representations you get upon deref. ... Best regards, Julian
Re: [File API] Recent Updates To Specification + Co-Editor
On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. I've just made the corresponding changes to FileWriter [-BlobWriter] in both the FileWriter and FileSystem specs. I've not changed the URL of the FileWriter spec, though, for simplicity. 2. I've updated the URL scheme for Blobs using an ABNF that calls for an opaque string which is a term I define in the specification. There was much discussion about this aspect of the File API specification, and I think the existing scheme does allow for user agents to tack on origin information in the URL (this is not something the spec. says you should do). The actual choice of opaque string is left to implementations, though the specification suggests UUID in its canonical form (and provides an ABNF for this). I think this is the most any specification has said on the subject of URLs. 3. There is an additional asynchronous read method on BlobReader, and an additional synchronous read method on BlobReaderSync, namely readAsArrayBuffer. These use the TypedArrays definition initially defined by the WebGL WG [4]. 4. I am moving on from my full-time role at Mozilla to a part-time consulting role. I'll continue to be an editor of the File API, but I am stepping down as Chair of the WebGL WG. I'll continue to be active in standards communities, though :-) 5. I spoke to Jonas Sicking, who expressed willingness to be a co-editor of the File API specification. Most people who work on HTML5 and WebApps know Jonas' contributions to both WGs; with everyone's consent, I'd like to nominate him as co-editor. His model for an asynchronous event-driven API is what prompted the initial rewrite, and he also works on both File API and IndexedDB implementation (amongst other things). Sounds good. Thanks Jonas! -- A* [1] http://dev.w3.org/2006/webapi/FileAPI/ [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0755.html [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0716.html [4] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
Re: [File API] Recent Updates To Specification + Co-Editor
On Mon, Jun 28, 2010 at 2:44 PM, Eric Uhrhane er...@google.com wrote: On Mon, Jun 28, 2010 at 2:20 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have made edits to the File API specification [1]. There are a few things of note that I'd like to call the WG's attention to. 1. There is a name change in effect. FileReader has been re-named BlobReader, upon request from Chrome team folks[2][3]. The name BlobReader won't win awards in a beauty pageant, but it tersely describes an object to read Blobs (which could originate from the underlying file system *or* be generated *within* a Web App). My present understanding is that FileWriter will also undergo a name change. Naming is really hard. Firefox already ships with FileReader, but I see the point of having an object named for what it does, which in this case is certainly more than file reading from the underlying file system. I also abhor bike shedding, especially over naming, but this is something that's exposed to the authors. I have not renamed FileError or FileException. In the case of errors and exceptions, I think *most* scenarios will occur as a result of issues with the underlying file system. These names should remain. I've just made the corresponding changes to FileWriter [-BlobWriter] in both the FileWriter and FileSystem specs. I've not changed the URL of the FileWriter spec, though, for simplicity. I have to say, I'm not a big fan of these name changes for two reasons: 1. While technically speaking, the functions on FileReader/BlobReader does accept Blobs rather than Files, I suspect that in most cases people will be dealing with files. I.e. I think it will be far more common that the Blob being passed in to the reader is in fact also a File, and is thought of by the developer as a file, than not. So while it seems strange to use a FileReader to read a Blob, it feels equally foreign to use a BlobReader to read a file. 2. Firefox 3.6 is already shipping with a FileReader implementation. Large parts of the spec remained stable and without request for changes for quite a while and we deemed it unlikely to change. Indeed, no other changes have been requested, other than the name change, in the parts that we implemented. I certainly agree that anyone shipping an implementation before a spec is an official Recommendation is always running the risk of running in to incompatible changes. However in the past we have avoided to break existing implementations, and I certainly can't think of a time we've decided to do it over what is essentially a bikeshed issue. / Jonas
Re: [File API] Recent Updates To Specification + Co-Editor
On Mon, Jun 28, 2010 at 3:06 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking jo...@sicking.cc wrote: I certainly agree that anyone shipping an implementation before a spec is an official Recommendation is always running the risk of running in to incompatible changes. However in the past we have avoided to break existing implementations, and I certainly can't think of a time we've decided to do it over what is essentially a bikeshed issue. Recently on your account a bunch of attributes named URL became url while they were already deployed in browsers based on WebKit. ;-) First of all, iirc there was already internal inconsistency in that webkit shipped properties named both .url and .URL. And so if the webkit devs wanted consistent naming, which seemed like a priority for everyone. Second, the url/URL name is much less likely to be used by existing content than the the FileReader/BlobReader name. It is quite possible to use EventSource and WebSockets without ever using the url/URL name, however it is impossible to use a FileReader without using the FileReader name. Third, I don't believe anyone raised the concern that there was likely content out there depending on the existing name. / Jonas
Re: [File API] Recent Updates To Specification + Co-Editor
On Mon, Jun 28, 2010 at 3:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 28, 2010 at 3:06 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 29 Jun 2010 00:01:14 +0200, Jonas Sicking jo...@sicking.cc wrote: I certainly agree that anyone shipping an implementation before a spec is an official Recommendation is always running the risk of running in to incompatible changes. However in the past we have avoided to break existing implementations, and I certainly can't think of a time we've decided to do it over what is essentially a bikeshed issue. Recently on your account a bunch of attributes named URL became url while they were already deployed in browsers based on WebKit. ;-) First of all, iirc there was already internal inconsistency in that webkit shipped properties named both .url and .URL. And so if the webkit devs wanted consistent naming, which seemed like a priority for everyone. Second, the url/URL name is much less likely to be used by existing content than the the FileReader/BlobReader name. It is quite possible to use EventSource and WebSockets without ever using the url/URL name, however it is impossible to use a FileReader without using the FileReader name. Third, I don't believe anyone raised the concern that there was likely content out there depending on the existing name. I believe Alexey Proskuryakov has strong feelings on this topic. Adam
Re: [File API] Recent Updates To Specification + Co-Editor
28.06.2010, в 15:37, Adam Barth написал(а): I believe Alexey Proskuryakov has strong feelings on this topic. I e-mailed public-webapps not long ago, but that seems to have gone unnoticed, http://www.mail-archive.com/public-webapps@w3.org/msg09236.html . - WBR, Alexey Proskuryakov
Re: [File API] Recent Updates To Specification + Co-Editor
On 6/28/10 3:41 PM, Alexey Proskuryakov wrote: 28.06.2010, в 15:37, Adam Barth написал(а): I believe Alexey Proskuryakov has strong feelings on this topic. I e-mailed public-webapps not long ago, but that seems to have gone unnoticed, http://www.mail-archive.com/public-webapps@w3.org/msg09236.html. Alexey: sorry if I overlooked responding to your original note. FWIW, we should separate URL/url and FileReader/BlobReader, since they are separate discussions. 1. URL vs. url: I agree that consistency is desirable, but almost *all* attributes *except constants* are expressed as lower case. URL/url is an exception (I'm very happy we gave up the *far* more confusing URN/urn -- I'm sorry I even considered it ;-)). I don't have a very strong opinion, so I'll defer to those that do, but to your point, Firefox also does ship 'document.URL' which seems likely the most common use of this property amongst authors. We don't *also* ship 'document.url.' My recollection is that Hixie changed a few things a while ago already, but I can't find a reference in email. This is bikeshedding to a certain extent, since developers will defer to documentation about attribute names. Given that a change has *already* occurred, do you *really* feel strongly enough to protest the change? 2. FileReader/BlobReader: I have a stronger opinion on this subject. Blob hasn't really landed on the web in a big way yet. Firefox's implementation doesn't do Blob, although we do File. While renaming the object BlobReader does account for the fact that all the arguments to the read methods are Blob arguments, there hasn't been too much discussion of what the majority use case will be. By majority use case I mean, what the object will be *mostly* used for. *Right now* Jonas points out that the majority use case is with Files. A good reason to rename it is if use cases emerge that are so compelling that manipulating Blob data generally might be just as desirable as manipulating user-selected files from the underlying file system. Can you or anyone cite such use cases? In either case, we're agitating on behalf of web developers. Having some weigh in would be useful in an implementor's bike-shedathon :-) -- A*
Re: [File API] Recent Updates To Specification + Co-Editor
On Mon, Jun 28, 2010 at 4:01 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/28/10 3:41 PM, Alexey Proskuryakov wrote: 28.06.2010, в 15:37, Adam Barth написал(а): I believe Alexey Proskuryakov has strong feelings on this topic. I e-mailed public-webapps not long ago, but that seems to have gone unnoticed, http://www.mail-archive.com/public-webapps@w3.org/msg09236.html. Alexey: sorry if I overlooked responding to your original note. FWIW, we should separate URL/url and FileReader/BlobReader, since they are separate discussions. 1. URL vs. url: I agree that consistency is desirable, but almost *all* attributes *except constants* are expressed as lower case. URL/url is an exception (I'm very happy we gave up the *far* more confusing URN/urn -- I'm sorry I even considered it ;-)). I don't have a very strong opinion, so I'll defer to those that do, but to your point, Firefox also does ship 'document.URL' which seems likely the most common use of this property amongst authors. We don't *also* ship 'document.url.' My recollection is that Hixie changed a few things a while ago already, but I can't find a reference in email. This is bikeshedding to a certain extent, since developers will defer to documentation about attribute names. Given that a change has *already* occurred, do you *really* feel strongly enough to protest the change? Right, this is completely orthogonal to the FileReader/BlobReader naming issue. 2. FileReader/BlobReader: I have a stronger opinion on this subject. Blob hasn't really landed on the web in a big way yet. Firefox's implementation doesn't do Blob, although we do File. While renaming the object BlobReader does account for the fact that all the arguments to the read methods are Blob arguments, there hasn't been too much discussion of what the majority use case will be. By majority use case I mean, what the object will be *mostly* used for. *Right now* Jonas points out that the majority use case is with Files. A good reason to rename it is if use cases emerge that are so compelling that manipulating Blob data generally might be just as desirable as manipulating user-selected files from the underlying file system. Can you or anyone cite such use cases? In either case, we're agitating on behalf of web developers. Having some weigh in would be useful in an implementor's bike-shedathon :-) Would definitely like to hear developer feedback. / Jonas
