- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 18 May 2010 14:40:24 -0700
- To: arun@mozilla.com
- Cc: Darin Fisher <darin@chromium.org>, David Levin <levin@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Fri, May 14, 2010 at 11:52 AM, Arun Ranganathan <arun@mozilla.com> wrote: > On 5/13/10 9:32 PM, Darin Fisher wrote: >> >> Glad to hear that you didn't intend sync access :-) >> > > I have thoughts on Blob and how it should behave (and about the inheritance > relationship between Blob and File), which is why I left the unfortunate > error in the editor's draft for now (commented out and caveated). This is > the subject of a separate email thread (but don't worry -- while my thoughts > on Blob and ArrayBuffer may be in some flux, sync access to File objects is > *always* going to be a no-no, I promise :-) ). > > Now aside from the Blob - ArrayBuffer relationship, which I introduced, the > rest of the changes are in keeping with threads discussing the File API. > >> Can you define the contentType parameter to slice better? Is that >> intended >> to correspond to the value of a HTTP Content-Type response header? For >> example, can the contentType value include a charset attribute? It might >> be >> useful to indicate that a slice of a file should be treated as text/html >> with a specific encoding. >> >> > > I'm happy to define it better in terms of what it *should* be, but web > developers are likely to use it in ways that we can't predict, which is why > "forcing" Content-Types is useful, but weird. Why exactly do you mean when > you say that a "slice of a file should be treated as text/html with a > specific encoding?" Can you give me a use case that illustrates why this is > a good way to define this? I can't speak for Darin, but I'd think the same reasoning that applies whenever a server adds those headers via HTTP should apply whenever a client-side app wants to add them to a Blob.url. >> I'm also a fan of providing a way to specify optional >> "Content-Disposition" >> parameters in the slice call. > > So I'm really not a Content-Disposition fan, since all the use cases I've > seen so far seem to be to "force download" behavior (or trigger Download > Manager). Is there something I'm missing -- e.g. is there something here > that FileWriter or BlobBuilder do *not* address, that putting > Content-Disposition on Blob URLs *does* address? Sorry if I'm missing > something obvious. It is indeed generally intended to trigger Download Manager. If you take a look at my use case at [1], the idea is to give web developers a facility that's just like the one they're already using, so that anything they do with URLs for files online they can also do with URLs for Blobs offline/client-side. The FileWriter spec's a bit up in the air over the same issue; I haven't yet specced a good way for FileWriter to solve this problem, so it's hard to say it's going to handle it better. Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0412.html
Received on Tuesday, 18 May 2010 21:41:36 UTC